如何在JGit中实现`git log --full-history [file]`功能？

我来帮你拆解这个问题——你遇到的情况其实和Git处理合并提交、文件历史追踪的默认行为直接相关，尤其是结合了合并还原的场景，咱们一步步理清楚：

1. Git默认git log [file]的行为逻辑 #

Git默认显示文件历史时，会开启简化历史（simplified history）模式：它会自动跳过那些“看起来没直接修改目标文件”的合并提交。这里的判断依据是合并提交的最终结果——如果合并后文件的内容和其中一个父提交的文件状态完全一致，Git就会认为这个合并提交对该文件没有“实质性改动”，直接从日志里排除它。

你提到的“分支还原旧提交后合并”的场景，刚好踩中了这个逻辑：合并提交的结果是把文件还原到了主分支某个旧状态，所以Git默认判定这个合并提交没修改文件，自然不会显示在git log [file]里。

2. --full-history的作用：强制关闭简化历史 #

--full-history参数会直接关闭Git的简化历史模式，它会遍历仓库里所有提交（包括合并提交），不管Git认为这些提交是否直接影响目标文件。哪怕合并提交的结果和某个父分支的文件状态一致，它也会被完整展示在日志中——这就是为什么你用这个参数能看到目标合并提交。

3. -m和--follow组合生效的原因 #

咱们分开看这两个参数的作用，再讲组合的魔力：

• -m：它会把合并提交拆分成多个“虚拟提交”，每个虚拟提交对应一个父分支的差异。简单说，Git会把合并提交当成多个独立的提交来分析，这样就能捕捉到合并过程中对文件的操作（哪怕最终结果和某个父分支一致）。但单独用-m时，因为还是在简化历史模式下，可能依然会被Git判定为“无改动”而跳过。
• --follow：它负责追踪文件的重命名历史，就算文件被改了名字，也能关联到之前的提交记录。但单独用它时，还是遵循简化历史规则，合并提交依然会被跳过。

当你把-m和--follow组合起来时：-m让Git拆分合并提交来深挖差异，--follow确保追踪文件的完整状态变化（包括还原操作带来的改动），两者联手绕过了默认的简化历史判断，所以能显示出目标合并提交。

4. 结合你的场景的具体分析 #

你的操作流程是：在分支上还原旧提交修改了文件 → 发起PR合并到主分支。这个合并提交的最终结果，大概率是让文件回到了主分支之前的某个状态，所以Git默认认为这个合并提交没“修改”文件（因为合并后和主分支父提交的文件状态一致），所以git log [file]跳过了它。而--full-history强制显示所有提交，-m --follow则通过拆分合并提交+追踪完整历史，让Git识别到这个合并过程中确实对文件做了还原操作，因此能显示出来。

稳定解决方案 #

如果你需要持续获取所有影响该文件的合并提交，推荐两种可靠方式：

• 方式一：git log --full-history [file]，简单直接，强制遍历所有提交，适合大多数场景。
• 方式二：git log -m --follow [file]，适合需要同时追踪文件重命名历史+合并提交细节的场景。

如果想更直观看到每个提交（包括合并提交）对文件的具体改动，可以加上-p参数，比如：git log --full-history -p [file]，这样能直接查看提交的diff内容。

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