合并后修订如何与功能分支关联？

Question

在学习 Git 时，对我来说最大的惊喜之一是修订不会永久与特定分支相关联。相反，一个分支仅仅指向一个特定的版本。一旦我完全内化了这个概念，我就意识到我不明白如何正确使用这个功能。

我读过一篇关于a successful Git branching model 的著名文章，其中将分支描述为线条，而修订则明显与一行相关联。考虑以下摘录：

                                       

这显示了两个功能分支（称为featureA 和featureB）和一个develop 分支。此外，featureB 被完全合并到develop 中，然后又短暂地分叉，只能重新合并。

这看起来不错、整洁且易于理解，并且恰好是回购在此过程结束时 字面意思在 Mercurial 之类的东西中的样子。我非常了解这一点，我喜欢它，并且我想像这样开发（在 Mercurial 中我做到了）。然而，在 Git 中，最终状态并非如此。它看起来像这样：

                             

换句话说，我们拥有的关于这两个特性分支的唯一信息是它们现在与开发分支处于相同的修订版。因此，我们可以推断出整棵树的最佳结果是：

                                 

换句话说，所有关于发展历史的好消息都丢失了；它一开始就没有被记录下来。观察第一张图中，三个修订版在合并到 develop 之前显然在 featureB 上，但我不明白我们如何知道这三个修订版在合并之前在 featureB 上。

这是正确的吗？以上是我在 Git 中事后可以恢复的最好方法吗？因此，这篇文章的截图是否具有误导性？还是我遗漏了什么重要的东西？

Answer 1

是的，没错，三个分支（指针）只会引用同一个提交。

但是对于 git，它更多的是关于提交的顺序，而不是关于一个分支。
分支只是提交图中的一个指针，目的是：

• 帮助本地开发者快速切换到一个或将一个与另一个合并
• 帮助发布（推送）到upstream repo 提交集合（默认情况下，您不会推送所有分支，只有一个希望公开)。

如果你真的需要在某处存储“featureA”，它会在提交消息中，但这不一定表示分支：你可以选择一个提交，重新设置一个分支，重命名删除一个随时分支（指针）。
最后，提交序列所讲述的故事比提交属于或属于一个或多个分支的事实更重要。

Answer 2

您部分正确，但也遗漏了一些东西。 Git 是关于提交序列和它们创建的图表的全部内容。但是您在最终图表中遗漏了三件事：

• （次要）您的最后一次合并是章鱼合并（合并两个以上的分支）。在那种情况下你不会这样做，而且我不知道为什么来自 git-flow 的图像也包含一个。
• 合并的父级有一个命令。所以有第一个父母和第二个父母。换句话说：git 记录 what 被合并 into what。
• 合并有提交消息

因此，您可以轻松地重建开发分支，从头开始并仅关注第一个父 (git log --first-parent)。

如果您想知道合并了哪个功能，可以查看合并中的提交消息。

但请注意，只有当您以这种方式使用 git 时，这才成立。将featureA 合并到develop 并将develop 合并到featureA 会得到非常相似的结果，而且很多人没有意识到它们之间存在差异。

Answer 3

正如@VonC 所指出的，在 git-land 中（与 Mercurial World 相对？:-)）似乎这通常被认为是一个特性，或者至少不是一个错误。但是，如果您希望标签保留在单独的空间中，您可以在 git 中通过与--no-ff 进行合并来实现这一点。这将创建一个“不必要”/“空”的合并提交，用于保持父指针分离，因此也用于保持分支分离。