项目结构重构后的Git分叉仓库如何同步旧仓库提交

你列的三个方案里，方案一直接排除，方案二仅适合结构改动极小的场景，优化后的方案三可行性非常高，是手动操作成本很低的选择，另外还有比这三个效率更高的原生Git实现思路，不需要手动改补丁路径、也不需要来回倒腾项目结构。

• 方案一（手动复制diff）：只适合old-repo fork后新增提交少于5个、总改动量不超过几百行的极端临时场景。只要提交量稍大，漏改逻辑、丢失提交历史的问题几乎必现，完全不适合你这种要归档旧仓库的一次性迁移场景。
• 方案二（回退结构再合并）：仅适合新旧版本目录差异不超过3处、重命名规则极其简单的项目。只要重构涉及多层目录调整、文件拆分合并，两次来回改结构的工作量甚至超过手动搬代码，后续解决结构回退再还原带来的冲突成本极高。
• 方案三（导出补丁改路径再应用）：完全可行，不存在技术上的卡点，我在好几个跨大版本重构的项目里用过类似思路。但手动打开patch文件做文本查找替换属于笨办法，容易因为路径匹配规则写错导致补丁打歪，Git本身自带路径映射参数，可以省掉手动改文件的步骤。

这个方案核心是利用Git内置的重命名检测、路径映射能力，全程不需要手动调整目录结构、不需要手动修改补丁内容，能完整保留所有提交的作者、时间、提交信息：

1. 先把old-repo添加为next-gen的远程源，拉取所有最新提交：

   git remote add old-repo <old-repo的本地路径或者远程仓库地址>
   git fetch old-repo
   

2. 找到两个仓库的fork点提交哈希，也就是最后一个两边共有的提交记录，记为base-commit，old-repo上fork之后持续迭代的分支记为old-repo/main。
3. 如果你清楚重构时的目录、文件重命名映射规则，直接用format-patch配合重命名检测参数生成补丁，再用git am的路径映射参数直接应用补丁，不需要手动改patch内容：

   # 生成fork点之后old-repo所有提交的补丁，自动识别文件重命名记录
   git format-patch -M --stdout base-commit..old-repo/main > old-repo-changes.patch
   # 应用补丁时直接指定路径映射，比如旧仓库根目录对应新仓库的packages/core/路径，多组路径映射可以加多个参数
   git am -p1 --directory='packages/core/' old-repo-changes.patch
   

   打补丁过程中如果遇到代码逻辑冲突，正常解决冲突后执行git am --continue即可，所有提交元信息都会完整保留。
4. 如果重构时的重命名规则太复杂，手动列路径映射容易出错，可以直接用带重命名检测的子树合并，连补丁生成的步骤都省了：

   # 调大重命名检测的文件数上限，避免因为文件太多检测失效
   git config merge.renameLimit 999999
   # 执行合并，自动识别文件重命名，把旧仓库改动映射到新仓库对应目录下
   git merge -s recursive -X rename-thresh=50 -X subtree=<新仓库中对应旧仓库根目录的路径> old-repo/main
   

   这个命令会自动匹配新旧仓库的文件对应关系，你只需要解决少量代码逻辑层面的冲突，不需要处理路径不匹配的问题。
5. 合并完成、验证功能正常后，移除之前添加的远程源即可：

   git remote remove old-repo
   

如果最终选择手动修改patch路径的方案，不要直接做全局文本替换，打补丁前先加--dry-run参数预执行，确认所有文件路径都能正确匹配后再实际应用，避免补丁打歪引入莫名其妙的问题。

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