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

Question

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

我读过一篇明显着名的关于a successful Git branching model的文章，该文章将分支描述为线条，而修订则与一条线条明确相关。请看这段摘录：

这会显示两个功能分支（称为featureA和featureB）和develop分支。此外，featureB已完全合并到develop，然后再次短暂分歧，只是重新合并。

这看起来很漂亮，整洁且可以理解，而且碰巧是回购在这个过程结束时字面看起来像是Mercurial。我理解这一点，我喜欢它，我想像这样发展（我在Mercurial中做过）。但是，在Git中，最终状态看起来并不像那样。它看起来像这样：

换句话说，我们关于两个功能分支的仅信息是它们现在与开发分支处于同一版本。因此，我们可以推断出整棵树的最佳结果是：

换句话说，关于发展如何发生的历史的所有好消息都丢失了;它从未被记录在首位。观察第一个图表中的三个修订版在featureB合并之前显然是develop，但我不知道我们怎么知道这三个版本在featureB之前是{{1}}合并。

这是对的吗？以上是我在Git后可以追回的最好的，并且是文章的截图，因此颇具误导性？或者有什么重要的我错过了吗？

Answer 1

是的，这是正确的，三个分支（指针）将引用相同的提交。

但是使用git，它更多地是关于提交的顺序而不是关于分支的 分支只是提交图中的指针，以便：

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

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

Answer 2

你是部分正确的，但也遗漏了一些东西。 Git就是提交顺序和它们创建的图形。但是你在最后的图表中遗漏了三件事：

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

因此，您可以轻松地重建开发分支，从头开始并仅跟随第一个父（git log --first-parent）。

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

但请注意，如果您以这种方式使用git，这只适用。将featureA合并到develop并将develop合并到featureA将会产生非常相似的结果，并且很多人都没有意识到存在差异。

Answer 3

正如@VonC所指出的那样，在git-land（而不是Mercurial World？:-)）中，通常认为这被认为是一个特征，或者至少不是一个bug。但是如果你希望你的标签在不同的空间中存在，你可以通过与--no-ff合并来实现这一点。这将创建一个“不必要的”/“空”合并提交，用于保持父指针分离，因此也用于保持分支分离。