修复git blame：文件已复制后显示原始文件历史

方案可行性分析 #

你的6步构造提交图的方案是可行的，核心逻辑是利用Git blame优先跟随第一个父提交的特性，通过伪装重命名的提交路径引导Git关联new.txt和old.txt的历史：

• 本质是在提交历史中插入一个“伪重命名”节点：先回退到new.txt被创建的提交之前，创建临时分支，将old.txt复制为new.txt并通过git mv old.txt new.txt标记为重命名，随后撤销old.txt的删除操作以保留两个文件，生成对应提交后，将原分支合并到这个临时分支（确保伪重命名提交作为第一个父提交），最后将结果推回原分支。
• 只要伪重命名提交的内容和原new.txt创建时的内容完全一致，Git blame就会优先跟随这个路径，从而关联到old.txt的历史。

替代方法 #

除了构造提交图的修改历史方案，还有两种无需改动历史的替代方式（但依赖手动执行参数，可能无法满足你“让git blame自动工作”的需求）：

• 使用git blame --follow new.txt：手动执行该命令时，Git会自动追踪文件的重命名/复制历史，但你无法控制IDE或GitHub的默认参数，所以无法自动生效。
• 使用git log --follow --find-copies-harder new.txt：该命令能更深入地查找文件的复制关系，追溯到old.txt的提交记录，但同样只能手动触发，无法让IDE或GitHub的内置blame功能自动关联历史。

快进合并的必要性 #

不是必须执行快进合并，但需要确保伪重命名提交作为合并后的第一个父提交：

• Git blame的逻辑是优先选择第一个父提交的历史路径，因此合并时需将包含伪重命名的分支作为当前分支，原分支作为待合并分支（即执行git merge original-branch），此时伪重命名分支会成为第一个父提交。
• 若使用非快进合并生成合并提交，只要第一个父提交是伪重命名提交，Git blame仍能正确跟随路径；快进合并只是让提交历史更线性，不会影响功能效果。

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