Git分支合并master后显示领先2200次提交的异常原因排查

遇到这种提交数统计明显不符合实际的情况，大概率是Git无法正确识别两个分支的最近共同祖先导致的，下面是几个最可能的原因：

• 你的分支历史被重写过
  如果你在开发分支上执行过git rebase、批量git cherry-pick，或者用git filter-branch/git rebase -i修改过提交历史（比如修改提交信息、合并多个提交、删除敏感文件等），这些操作会改变原有提交的哈希值。Git是通过提交哈希来追踪历史的，一旦哈希改变，Git会把这些重写后的提交当成全新的提交，而不是基于原master分支的延续。当你合并master到自己分支时，Git找不到正确的共同祖先，就会把你分支上所有重写后的提交（加上后续新增的）都算成"领先"的提交，导致统计数字严重虚高。

• master分支的历史被远程强制改写过
  如果团队里有人对远程master分支执行了git push --force操作（比如修复了历史中的错误提交、合并了需要重写历史的大分支），你本地的master分支在拉取远程更新后，历史会出现分叉或者大量"新"提交（其实是重写后的旧提交）。这时候你的开发分支是基于旧的master历史创建的，和新的master分支的共同祖先会回到很早的位置，Git统计时就会把你分支上从那个古老祖先到现在的所有提交都算成领先于master的数量，自然就远高于实际的几十次。

• 错误的分支操作导致历史分叉
  比如你可能在创建分支时误操作，不是基于当时最新的master分支，而是基于某个很早的标签、其他分支或者本地旧的master版本。后续master更新了一百次，你的分支更新了几十次，但两个分支的共同祖先非常早，导致Git计算领先次数时，把你分支上从共同祖先到现在的所有提交都算进去，加上master的提交数，就出现了夸张的数字。不过这种情况概率较低，毕竟你说创建时是基于master的。

• Git统计逻辑的"视觉误差"
  有时候Git显示的"领先X次提交"并不是指你新增的提交数，而是两个分支从共同祖先开始的提交总数之差。比如如果共同祖先之后，master有100次提交，你的分支有2300次（包括重写后的重复提交），那Git就会显示你领先2200次，这其实是把所有非重叠的提交都算进去了，而不是你实际新增的提交。

快速验证和解决思路 #

1. 先查看两个分支的历史关系，执行git log --oneline --graph master..your-branch，看看提交历史是不是有大量重复或者奇怪的分叉。
2. 检查master分支的远程同步情况，执行git fetch origin，然后git diff origin/master master，看看本地master和远程master是否有差异。如果远程master被重写过，需要用git reset --hard origin/master强制同步本地master（注意先备份本地未提交的修改）。
3. 如果是自己分支的历史被重写导致的，你可以考虑重新基于最新的master创建新分支，然后用git cherry-pick把你真正需要的提交移过去，避免历史混乱；或者如果团队允许，直接把重写后的分支强制推送到远程，但这会影响其他协作的同事。

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