跨仓库合并不是一键merge能解决的事，核心在于明确目标：搬代码、搬提交还是搬完整历史；必须加--allow-unrelated-histories才能合并无共同祖先的仓库，git merge -s subtree可将项目作为子目录合并并保留历史，git cherry-pick适合搬运特定提交，而git pull因隐式merge且缺参数易失败，推荐先fetch再显式操作。
直接说结论：跨仓库合并不是“一键 merge”能解决的事，核心在于你到底要什么——是搬代码、搬提交、还是搬完整历史？选错方法，后续维护会持续掉坑。
git merge --allow-unrelated-histories 什么时候必须加
Git 2.9+ 默认拒绝合并两个没有共同祖先的仓库，报错 fatal: refusing to merge unrelated histories。这不是 bug，是保护机制。
- 必须加
--allow-unrelated-histories的场景：你用git remote add拉入另一个仓库后，直接git merge它的分支（比如origin/main） - 少一个
s（写成--allow-unrelated-history）就会报错，参数名必须严格匹配 - 它只影响本次操作，不改配置、不改后续行为
- 如果合并后满屏
CONFLICT (add/add)，说明两个仓库根目录文件大量重名——这不是参数问题，是路径设计问题，得先做子目录隔离
git merge -s subtree 合并项目为子目录
想把仓库 A 的全部代码作为子目录（比如 legacy-a/）塞进仓库 B，而不是平铺到根目录，必须用 -s subtree 策略。
- 先执行
git remote add a-repo /path/to/a（本地路径也行，不用推远程） - 再
git fetch a-repo，这时它的主分支叫a-repo/main - 关键命令：
git merge -s subtree --allow-unrelated-histories a-repo/main—— 缺-s subtree就是平铺，加了才自动移进子目录 - 合并后，A 的所有提交历史保留，且每个文件路径前自动补上
legacy-a/（实际目录名由 Git 自动推断，也可用git read-tree手动指定） - 后续还能用
git subtree pull或git subtree push和 A 保持单向同步（如果需要）
git cherry-pick 跨仓库搬特定提交
只想要对方仓库里某几个提交（比如修复 bug 的 commit），而不是整个历史或全部代码，git cherry-pick 最干净。
- 在目标仓库 B 中，先加远程：
git remote add repo-b https://xxx.git - 拉取：
git fetch repo-b - 挑 commit：
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，它隐式触发了 merge 行为，而默认策略不处理无共同祖先的情况。
- 你没显式写
--allow-unrelated-histories，pull会直接失败，不会给你提示该加啥参数 - 即使成功（比如旧版 Git），也可能因策略误用导致文件被覆盖、历史断裂、
git bisect失效 -
pull还会自动创建 merge commit，但你往往并不需要这个 commit——尤其当只是临时搬代码时 - 真正可控的做法永远是分步：先
fetch，再明确用merge或cherry-pick，参数和策略自己定
最常被忽略的一点：跨仓库合并后，别急着 git push。先 git log --graph --oneline --all 看一眼图谱，确认历史结构符合预期——特别是 subtree 合并后，A 的提交是否真的挂到了 B 的某个子树下，而不是散落在顶层。图谱乱了，后面 revert、rebase、协作都容易出问题。
