Git合并后分支B文件历史不显示疑问：为何仅展示分支A历史？

嘿，这事儿我碰到过好几次，一开始也懵——明明合并前B分支上这个文件有自己的提交记录，怎么合并A之后就只剩A的历史了？别担心，B的历史根本没丢，只是Git默认的日志展示逻辑在“搞事情”～

为什么默认看不到B的文件历史？ #

Git的文件历史追踪是基于内容继承关系的：当你把A合并到B时，如果A分支对这个文件的修改是最后生效的（比如合并时没有冲突，或者冲突解决后用了A的版本），默认的git log <file>会自动沿着“内容来源”的提交链展示，也就是只显示A分支上的提交，而把B分支之前的提交暂时隐藏了——这是Git为了让你快速看到当前文件内容的演变路径，做的简化处理。

另外要注意：如果你的合并是快进合并（也就是合并前B分支没有任何新提交，A是从B分出去后单独开发的），那合并后历史是线性的，B的提交本来就在A的历史里，这时候不会出现“看不到B历史”的情况，所以你的情况应该是用了普通的三方合并（生成了合并提交）。

怎么找回B分支的文件历史？ #

用这几个命令就能看到完整的历史：

• 查看所有分支的文件提交记录：
  执行git log --full-history --oneline <你的文件路径>
--full-history参数会强制Git展示该文件在所有分支上的提交，不管合并时的内容选择，这样B分支之前的提交就会显示出来了。
• 可视化分支合并关系：
  想更直观看到合并节点和两边的历史，用git log --graph --oneline <你的文件路径>
  这个命令会画出分支合并的图形，你能清楚看到合并提交同时指向B的最后一个提交和A的最后一个提交，两边的文件历史都一目了然。

举个例子：假设合并前B有提交b1、b2，A有提交a1、a2，合并后生成提交merge-M。默认git log <file>会输出merge-M → a2 → a1，但用--full-history就会输出merge-M → b2 → b1和merge-M → a2 → a1两条链。

小提醒 #

如果合并时存在冲突，且你解决冲突时保留了B分支的部分内容，那默认日志可能会同时显示部分B的提交，但如果完全用了A的版本，就会只显示A的链——但不管哪种情况，--full-history都能帮你找回所有历史。

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