为什么在git合并后删除分支？

Question

我有Mercurial的经验，在合并后我们关闭分支。 但是，我们不会删除源分支，因此，如果发现问题，我们可以跟踪master分支中的所有合并，以大致确定问题的来源（分支）。 然后，我们跟踪分支的提交以识别罪魁祸首。

在git中，我读到我们应该在merge之后删除分支 。 我的问题是

1. 为什么？ 如果发现错误，我们如何识别已合并到master的错误提交？

2. 通常，您的git家伙如何跟踪历史记录以识别错误的提交？

Answer 1

首先，与Mercurial的分支相比，Git分支是“匿名的”。

这意味着，记录在“一个”分支上的提交（大多数都是，但这不是必需的）， 不包含有关其提交到的分支的信息 。 这是故意的。 在此模型中，分支仅仅是指向某些提交的“指针”，通过父/子关系，这些提交可用于向后遍历更改的历史记录。

结果是可以通过任意数量的分支（和标签）来访问记录在存储库中的任何提交。 因此，在此模型中，任何提交都可以同时“在”任何数量的分支上。

其次，合并提交不仅记录要合并的分支的名称（这只是默认行为；通过命名其尖端提交或覆盖/编辑合并消息来合并历史链是完全合法的），但实际上是尖端提交合并时该分支的名称。 因此，此信息记录在合并提交本身中，并且该历史记录永久存在于该行中：例如，如果您将分支B合并到分支A中，从而导致合并提交M，则可以在该分支B的尖端处引用它。通过M^2进行合并的时间，这意味着“ M的第二父级”（第一父级是合并时A的尖端）。

鉴于Git分支是轻量级的，如果您需要在合并时“及时返回”以“处理” B，则只需执行

$ git checkout -b oldB M^2

这就是“创建一个名为«oldB»的新分支，指向合并提交«M»的第二个父分支并检出它”。

探索完B的旧状态后，只需摆脱该“ oldB”分支即可。

---

总而言之，Git最好从另一个角度进行研究：考虑互连提交的图形，其中分支仅指向该图形的某些“入口点”。

Answer 2

只是在kostix的回答中添加了一点：在Mercurial中，提交永久地固定在一个分支 上 ，因此包含在其中 。 包含提交的分支是进行提交时的当前分支。

这意味着看起来像这样的图是明智的：

branch1:  C1 <-C2 <-C3 <-M
                        /
branch2:    C4 <-C5 <-C6

因为提交将始终在这些分支上。

在Git中并非如此：如前所述，每个Git提交都位于零个或多个分支上，并且该集合随时间动态变化。 我们应该将分支名称放在右侧，并从其中伸出箭头，指向提交，而不是将名称放在左侧并让其向右“逆向”指向后的箭头流动：

C1 <-C2 <-C3 <-M   <-- branch1
              /
  C4 <-C5 <-C6   <-- branch2

这使我们可以将名称移动，甚至移动到图的其他行，而不必担心哪个提交在其右边。 流程完全是从右到左，没有混合。