Git 标记和 Gitflow : What happens when you merge old commits

Question

我对标记感到非常困惑，需要澄清一些事情。对于源代码控制，我喜欢使用“gitflow”工作流程。我通常从开发中创建功能分支，一旦完成，我将 merge 回开发，然后在一个发布周期中，一个发布分支将从开发中分离出来，并最终进入主分支。 merge 到 master 后，我用版本号标记顶部提交。

想象以下场景:

master 分支带有“v1.0”标签，其中包含来自 develop 的所有最新代码。另一个团队成员将他已经工作了数周的分支 push 开发阶段。其中一些分支在标记的创建日期之前提交。最终，这些旧提交构成了一个发布分支，并通过 merge 找到了进入 master 的方式。如果我查看 git 历史记录，我可以在主分支日志中看到更远的旧提交。

如果我现在将顶部提交( merge 提交)标记为“v1.1”，那么我的项目会在哪里？如果我 checkout 标签“v1.0”，它现在会包含旧的提交，因为它们在历史中更远吗？我标记的原因是我可以在必要时在版本之间来回跳转，但是如果旧的提交会在工作中抛出一个 Spanner ，我不知道该怎么做!

Answer 1

我今天自己问了这个问题，所以我阅读了一些文档并进行了一些测试提交。

看看我的测试存储库 https://github.com/pixelbrackets/hello-github-world/

我在 »version.txt« 中做了九次提交，将连续的数字添加到文件中:

master 中的两次提交

标记发布版本 0.1.0(有两次提交)

切换到功能分支

在功能分支中创建了两个提交

切换回主

在 master

中创建了两次提交

标记发布版本 0.2.0(现在有四个提交，还不包括该功能)

切换回功能分支

在功能分支中创建了另外两个提交

将master merge 到特性分支并解决 merge 冲突

将功能分支 merge 到 master

标记发布版本 0.3.0(有 9 次提交 - 4 次来自 master，4 次来自功能分支，1 次 merge 提交)

删除了功能分支

问题是:在第 4 步中的两个预先提交的提交 merge 回 master 之后会发生什么？

好吧，正如 Oliver Charlesworth 在他上面的评论中已经解释的那样，提交不是通过日期联系起来的。重要的是拓扑顺序。
但是，当您查看 git log 时，默认情况下提交按时间倒序显示。这可能会导致这种困惑的情况。

要按拓扑顺序查看 git 历史记录，您可以使用图形工具，如 »gitg« 或在命令行中键入 »git log --topo-order --graph«。

这是我的测试提交的屏幕截图，使用 »gitg« 制作:



正如您在右列中看到的，所有提交都按连续顺序排列。但是尽管我删除了功能分支，图表仍然清楚地表明提交 3、4、7、8(步骤 4 和 9)是分开进行的。标签名称显示在相应提交旁边。

当我 checkout 第二个标签时，不包括第四步的提交。

$ git checkout 0.1.0
HEAD is now at d76c450... Commit 2 Master 2
$ cat version.txt 
1
2
$ git checkout 0.2.0
HEAD is now at 3eeec86... Commit 6 Master 4
$ cat version.txt 
1
2
5
6
$ git checkout 0.3.0
HEAD is now at 699c6f1... Fix Merge Conflict
$ cat version.txt 
1
2
3
4
5
6
7

因此，不，git 标签不会包含较早创建并在后续日期 merge 到分支中的提交。您可以使用标签作为发布版本，就像您期望它们工作一样。