Git合并后为何删除分支？Mercurial分支管理差异及排障疑问

嗨，作为长期用Git的开发者，我完全理解你从Mercurial转过来的困惑——毕竟两者在分支设计上确实有不小差异，我来帮你拆解清楚：

首先得明白Git和Mercurial分支的本质区别：

• Mercurial的分支是仓库级别的实体，创建后会和仓库绑定，保留分支是为了明确追踪分支线；
• 而Git的分支只是指向某个提交的轻量指针，它本身不占多少存储空间，创建、删除都极快。

推荐合并后删除分支主要有两个原因：

1. 保持仓库整洁：大部分场景下，功能分支、修复分支都是临时的——它们的使命就是完成某个需求或修复，合并到主分支后就没有存在的必要了。留着一堆已完成的分支，会让分支列表变得杂乱，新成员看了也容易困惑。
2. 符合Git主流工作流：不管是GitHub Flow、Git Flow还是Trunk-Based Development，临时分支都是用完即弃的。比如Git Flow里的feature分支，合并到develop后就可以删除，后续如果要迭代，直接从最新的develop拉新分支就行。

而且你完全不用担心删除分支会丢历史——Git删除分支只是删掉那个指针，分支上的所有提交依然保存在仓库的提交历史里，和Mercurial一样完整。

虽然分支删了，但Git有一堆工具帮你快速定位Bug来源，甚至比Mercurial更灵活：

• 查看合并提交历史：用git log --oneline --graph命令，能看到可视化的提交图谱。每个合并提交都会显示它的两个父提交——一个是主分支的最新提交，另一个就是被合并的临时分支的最后提交。通过合并提交的信息（比如你合并时写的“Merge feature/payment-fix into master”），就能快速关联到对应的功能改动。
• 用git blame定位代码行：如果知道Bug出在某个文件的某一行，直接运行git blame <文件名>，就能看到每一行的最后修改提交ID、作者和时间，顺着提交ID就能追溯到具体的分支改动。
• git bisect二分查找Bug：这是Git最强大的Bug定位工具之一。如果不知道具体哪次提交出问题，你可以用它快速缩小范围：
  1. 先执行git bisect start启动二分查找；
  2. 标记当前有问题的版本为git bisect bad；
  3. 标记一个已知没问题的旧版本为git bisect good <提交ID/标签>；
  4. Git会自动跳到中间的提交，你测试这个版本是否有Bug，然后用git bisect bad或git bisect good继续标记，直到找到第一个引入Bug的提交。
• 查看提交关联的分支痕迹：即使分支删了，你依然可以用git reflog查看仓库的所有操作记录，找到曾经的分支指针指向的提交，不过这个一般是应急用的，日常用前面几个方法足够。

总体来说，Git的分支设计更偏向“临时工具”，删除分支只是清理指针，不会影响历史追踪；而它的提交追踪工具反而更丰富，完全能满足你定位Bug的需求。

内容的提问来源于stack exchange，提问作者AlexTP