版本在合并后如何与功能分支关联？

Question

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

我读过关于a successful Git branching model的明显着名的文章，其中描述了分支为线条，修订为与一条线明确关联。考虑这个摘录：

                                                     

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

这看起来不错，整齐和可以理解，也正好是回购字面上看起来像在这个过程的结尾像Mercurial。我明白这一点，我喜欢它，并且我希望像这样发展（我在Mercurial中也这样做了）。然而，在Git中，最终状态并不像这样。它看起来像这样：

                                       

换句话说，我们对两个特征分支只信息他们现在是一样的修改为开发分支。因此，我们可以推断出整个树最好是这样的：

                                             

在其他单词，所有那些很好的信息ab走出发展如何失去的历史;它从来没有记录在第一位。观察第一张图中的三个修订版在清除featureB之前如何合并为develop，但我没有看到我们如何知道这三个修订版在合并前的featureB上。

这是正确的吗？以上是我能够在Git中事后恢复的最好结果，并且是来自论文的截图，因此颇具误导性？还是有什么重要的我失踪？

Answer 1

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

但是使用git，它关于提交的顺序比关于分支更多。
分支只是在提交的图形的指针，以便：

• 帮助当地开发商快速切换到一个或者兼并一个与另一个
• 帮助发布（推）到一个upstream repo提交的集合（你不推全部默认分支，只有一个想公开）。

如果你真的需要存储“featureA”的地方，这将是值的信息，但不会有必要指出的一个分支：你能摘樱桃的提交，变基的一个分支，重命名的删除一个分支（指针）在任何时候。
最后，提交顺序告诉的故事比提交所属或属于一个或多个分支的事实更重要。

Answer 2

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

Answer 3

你是部分正确的，但也缺少一些东西。 Git是关于提交序列和他们创建的图表的。但是你在最终图中缺少三件事：

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

所以，你可以很容易地重建发展分支，通过开始在其头部和下只有第一父（git log --first-parent）。

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

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