git - merge 后修订如何与功能分支相关联？

Question

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

我读过关于 a successful Git branching model 的著名文章，它将分支描述为线，并将修订描述为与一条线明确关联。考虑以下摘录:

这显示了两个功能分支(称它们为 featureA 和 featureB)和一个 develop 分支。此外，featureB 已完全 merge 到 develop 中，然后再次短暂 fork ，然后重新 merge 。

这看起来不错、整洁且易于理解，而且恰好是在这个过程结束时，在类似 Mercurial 中的 repo 字面上的样子。我非常了解这一点，我喜欢它，并且我想像这样开发(我在 Mercurial 中做到了)。然而，在 Git 中，最终状态看起来并不像那样。它看起来像这样:

换句话说，我们所掌握的关于这两个功能分支的唯一信息是它们现在与开发分支处于相同的修订版中。因此，我们可以为整棵树推断出的最好结果是:

换句话说，所有关于开发历史的重要信息都丢失了；它从来没有被记录在首位。观察第一个图中，三个修订在 merge 到 develop 之前清楚地在 featureB 上，但我不明白我们如何知道这三个修订在featureB merge 前。

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

Answer 1

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

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

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

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