Git 标记问题

Question

即使在阅读了文档之后，我也对 git 标记感到有些困惑。

假设我正在更改我的 develop 分支。

1. 我应该在更改之前创建标签，还是应该在更改之后添加标签？哪个工作流程更好？

2. 最初我被要求只使用git push --tags，但在运行git tag 之后，当我尝试运行git tag -v release-5 时，我看到了一个包含5 个标签的列表（release-1、...、release-5）提示以下错误，其他版本也一样。 有什么想法吗？

   error: 575bbe56b0c021c51e2b819763c1ff15cc5d2186: cannot verify a non-tag object of type commit.
   error: could not verify the tag 'release-5'
   

3. 如果我在Develop分支中使用git push推送标签，然后合并到Master分支，是否还需要再做一轮git push --tags

4. 标签与分支有何不同？哪个更好？

Answer 1

我是否应该在进行任何更改之前先创建一个标签，尽管我知道我可以在更改后对其进行标记。哪个工作流程更好？

您不必这样做，但如果您想回到已确定的点，它会有所帮助。

您需要注意两种标签（如git tag 中所述）：

• lightweight tags（提交对象的 SHA-1 对象名称参考）
• annotated tags（独立标记对象，包括创建日期、标记者名称和电子邮件、标记消息和可选的 GnuPG 签名）： git tag -a myTag 或 git tag -m "new myTag" myTag 都创建了带注释的标签。
  git tag myTag 仅创建轻量级标签。

带注释的标签用于发布，而轻量级标签用于私有或临时对象标签。

无法验证提交类型的非标记对象。

您只能验证带注释的标签，因为它是一个独立的对象，可以支持可选的 gpg 签名（即您尝试使用 -v 选项验证的签名）。
轻量级标签只是提交的捷径。

git push --tags 在Develop 分支中：

这是一项会影响您的远程upstream repo的操作。
它会推送 all 标签，而不仅仅是在 Develop 分支中设置的标签。
只推送重要的，I recommend git push --follow-tags

然后合并到Master 分支，

这是在您的 local repo 中完成的 local 操作，与之前刚刚完成的 git push 无关。

我还需要再做一轮 git push --tags

这两个操作完全不相关。

标签与分支有何不同？哪个更好？

与 SVN 相比，标签与分支有很大不同，并补充了它们：一个并不比另一个好。

• 分支用于隔离开发工作（请参阅“When should you branch?”）。
• 标签用于将历史中的特定点标识为重要的（例如，用于标记发布）。

可以轻松重命名或删除分支。
（注释）标签不能被修改而不影响git repo的历史。

Answer 2

首先，VonC 的解释很好。 现在转到您的问题，关于标记的工作流程，

1. 你必须用轻量级或带注释的标签（选择是你的）标记你的 git repo 的初始版本，通常我更喜欢带注释的标签。 {P.S：拥有标签的初始版本总是更好。这不是必须的。 }
2. 然后进行更改、提交并推送它们。同样你可以简单地使用 git tag 命令来创建一个标签，你必须使用“git push origin --tags”来推送它。
3. 一旦完成，您的标记就与您的更改一起完成。 现在，如果您可以使用“git diff tag1 tag2”检查差异。

希望对你有帮助:)