Git合并含文件重命名分支且两侧均做格式化时出现冲突如何解决

调整find.renames阈值无效，本质是没搞清楚Git重命名检测的运行逻辑：

• Git做重命名识别时，永远拿两个分支的共同祖先提交当对比基准，不会直接比对develop和next两个分支端点的文件内容
• 你的场景里，共同祖先上的文件状态是「旧路径+未格式化内容」：
  • develop相对祖先的改动是「保留旧路径+全量格式化改内容」
  • next相对祖先的改动是「移动到新路径+全量格式化改内容」
• 全量格式化会把文件内容100%改写，Git算两边相对祖先的文件相似度时，会直接判定两边文件没有关联——哪怕develop和next上格式化后的文件内容一字不差，也认不出来这是同一个被移动的文件。
• 还有个很容易踩的坑：Git默认的merge.renameLimit值是1000，全库格式化涉及的文件数超过这个阈值时，Git会直接关掉重命名检测保性能，这种情况你把相似度阈值调到0都没用，因为检测流程根本没跑。

按长期稳定性和操作成本从高到低排：

方案1：拆分不同类型的改动（一劳永逸，零额外冲突） #

这是从根上解决问题的方式，核心规则是文件移动、全量格式化、业务逻辑修改三类操作绝对不要混在同一个提交里：

1. 切到next分支，用git mv命令完成所有文件的路径移动，这一步不要改任何一行文件内容，单独提交，提交信息明确标注是纯路径调整。
2. 把这个纯移动的提交cherry-pick到develop分支，保证两个分支的目录结构完全一致，不存在路径差异。
3. 分别在两个分支上跑代码格式化工具，单独提交纯格式化改动，这一步不要夹带任何路径调整、业务代码修改。
4. 之后按原有流程正常把develop合入next就行，Git能完整识别所有改动历史，不会再出现批量的重命名相关冲突，后续长期同步也不会再出同类问题。

方案2：调整合并检测配置（适合已经把改动提交完、不想回退重写历史的场景） #

如果已经把格式化、路径移动的改动混进了现有提交，不想回退重做，可以在合并时临时调整Git配置，强制跑全量重命名识别：

1. 先把重命名检测的文件数上限拉满，避免Git因为文件太多跳过检测流程：

git config merge.renameLimit 999999

2. 执行合并时手动指定较低的相似度阈值，强制Git跨路径匹配关联文件：

git merge develop -X find-renames=10%

这个配置下Git会遍历所有文件做相似度计算，只要两个文件相对祖先有10%以上的内容重合，就会尝试匹配重命名关系，能解决绝大多数批量冲突。

方案3：批量处理残留冲突 #

如果跑完上面的操作还有少量冲突，且你确认next分支上对应文件除了路径移动和格式化之外，和develop的格式化后内容完全一致，可以写个简单脚本批量处理delete/modify类型的冲突：把develop分支的改动直接应用到next分支对应的新路径文件上，不用手动逐个解冲突。

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