Question

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

在git中，我读到we should delete branch after merge。我的问题是

为什么呢？如果发现错误，我们如何识别已合并到master的错误提交？
一般来说，你如何跟踪历史记录以确定错误的提交？

Answer 1

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

这意味着，“在”分支上记录的提交（大多数是，但这不是必需的）承担没有关于分支的信息 承诺。这是故意的。在这个模型中，分支只是“指针”指向某些提交父/子（ren）关系 - 可用于向后遍历变化的历史。

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

其次，合并提交不仅记录分支的名称合并（这只是默认行为;它完全合法通过命名其提示提交或覆盖/编辑来合并历史链合并消息）但实际上是当时该分支的提示合并。所以这些信息记录在合并提交本身，那段历史永远在那里：比方说，如果你已经合并了分支B进入分支A导致合并提交M，你可以参考通过M^2合并时该分支B的尖端意味着 “M的第二个父母”（第一个父母是当时的A的尖端合并）。

鉴于Git分支是轻量级的，你需要吗？在合并时“及时回到”“工作”B，你可以做到

$ git checkout -b oldB M^2

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

在你完成探索B的旧状态之后，就摆脱它 “oldB”分支。

总结一下，Git最好从另一个角度来看待：从长远来看互连提交的图表只有指向的分支对该图表的某些“切入点”。

Answer 2

只需向kostix's answer添加一点：在Mercurial中，提交永久地附加到，因此包含在中只有一个分支。包含提交的分支是提交时的当前分支。

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

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

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

在Git中并非如此：如上所述，每个Git提交都在零个或多个分支上，并且该集合会随着时间的推移而动态变化。我们应该将分支名称放在右边并且有箭头从它们出来，指向提交，而不是将名称放在左边，让它向右“向后”向后指向箭头：

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

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

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

2 个答案: