跨仓库合并代码：别让“一键操作”埋下技术债

开门见山，先说结论：跨仓库合并不是一个简单的“一键合并”按钮就能搞定的事情。问题的核心在于，你一开始就得想清楚——你到底想要什么？是把代码文件挪过来就行，还是需要特定的几个提交，又或者是必须保留完整的项目历史？方法选错了，后续的维护工作就会变成一个接一个的坑。

git merge --allow-unrelated-histories：什么时候必须加？

从 Git 2.9 版本开始，如果你试图合并两个完全没有共同祖先的仓库，它会直接报错：fatal: refusing to merge unrelated histories。这可不是什么程序缺陷，而是 Git 内置的一种保护机制，防止你误操作。

• 必须使用这个参数的场景：当你通过 git remote add 添加了另一个仓库的远程地址后，想直接合并它的某个分支（例如 origin/main）到当前分支。
• 注意一个细节：参数名是复数 histories。少写一个字母 s（写成 --allow-unrelated-history）都会导致命令执行失败，必须严格匹配。
• 这个参数只对当前这一次合并操作生效，它不会修改任何全局配置，也不会影响后续的合并行为。
• 如果合并后出现了满屏的 CONFLICT (add/add) 冲突，这通常不是参数用错了，而是意味着两个仓库的根目录下存在大量同名文件。这时候，问题的本质是项目路径设计冲突，你得先考虑如何做好目录隔离，而不是纠结合并命令。

git merge -s subtree：如何将整个项目作为子目录合并

如果你的目标不是把仓库A的代码平铺到仓库B的根目录下，而是希望将A作为一个子目录（比如 legacy-a/）整体嵌入到B中，同时还要保留A的全部提交历史，那么 -s subtree 合并策略就是你的不二之选。

• 首先，添加远程仓库：git remote add a-repo /path/to/a（使用本地路径也可以，不一定非要远程仓库）。
• 接着，获取数据：git fetch a-repo。完成后，远程仓库A的主分支在你本地会被引用为 a-repo/main。
• 关键命令在这里：git merge -s subtree --allow-unrelated-histories a-repo/main。如果缺少 -s subtree 参数，合并结果就是平铺；加上它，Git 才会自动将A的所有文件“挪进”一个子目录。
• 合并成功后，仓库A的所有历史提交都会被保留，并且每个文件的路径都会自动被加上类似 legacy-a/ 的前缀（具体的目录名由 Git 自动推断；如果需要精确控制，也可以使用 git read-tree 命令手动指定）。
• 后续如果还需要与源仓库A保持单向同步，可以使用 git subtree pull 或 git subtree push 命令来操作。

git cherry-pick：精准搬运特定的提交

有时候，你并不需要另一个仓库的全部代码或完整历史，可能只是看中了对方修复的某个关键Bug，或者几个特定的功能提交。这种情况下，git cherry-pick 是最精准、最干净的选择。

• 在目标仓库B中，先添加源仓库的远程地址：git remote add repo-b https://xxx.git。
• 拉取提交数据：git fetch repo-b。
• 然后就可以“采摘”特定的提交了：使用 git cherry-pick abc1234 采摘单个提交，或者用 git cherry-pick abc1234 def5678 批量采摘多个。
• 这里有个区间写法的细节需要注意：git cherry-pick a1b2c3^..d4e5f6 表示采摘从 a1b2c3 到 d4e5f6 的所有提交（包含两端，即“双闭区间”）；而 git cherry-pick a1b2c3..d4e5f6 则表示从 a1b2c3 的父提交开始，到 d4e5f6 结束（前开后闭）。
• 如果采摘过程中发生冲突，解决冲突后，必须使用 git add . && git cherry-pick --continue 来继续流程，而不能直接执行 git commit。

为什么不推荐使用 git pull 进行跨仓库合并？

表面上看，git pull other-repo main 这个命令非常简洁，但它的本质是 fetch 和 merge 两个操作的组合。问题就在于，它隐式地触发了合并行为，而默认的合并策略并不处理“无共同祖先”这种特殊情况。

• 如果你没有显式地加上 --allow-unrelated-histories 参数，pull 命令会直接失败，而且通常不会给出清晰的提示告诉你该加什么参数。
• 即使在旧版本的 Git 中侥幸成功了，也可能因为策略误用而导致文件被意外覆盖、提交历史出现断裂，甚至影响 git bisect 等依赖历史完整性的工具的正常使用。
• 此外，pull 命令会自动生成一个合并提交（merge commit），但很多时候你并不需要这个额外的提交记录——尤其是当你只是临时搬运一些代码的时候。
• 因此，真正可控、可靠的做法永远是分步操作：先 fetch 获取数据，然后再根据你的具体需求，明确地选择使用 merge（并指定策略和参数）或 cherry-pick。把控制权握在自己手里。

最后，分享一个至关重要的检查步骤，也是最容易被忽略的一点：跨仓库合并操作完成后，先别急着执行 git push。务必用 git log --graph --oneline --all 命令看一眼提交历史图谱，确认合并后的历史结构完全符合你的预期。特别是使用了 subtree 合并后，一定要检查仓库A的提交是否真的整齐地挂载在了仓库B的某个子树下面，而不是散落在顶层。图谱一旦乱了，后续的回退、变基以及团队协作，都会变得异常棘手。