Git合并源于同一祖先的两个互斥repository问题求助

我刚好处理过几乎一模一样的场景，咱们一步步拆解问题、解决它：

问题根源 #

你遇到大量冲突的核心原因是：A和B从Z分叉后，各自删除了对方的核心文件，后续迭代又积累了独立的提交历史。Git的subtree merge默认会对比所有历史差异，两边都坚持自己的文件状态是“正确”的——A认为B的文件应该被删除，B认为A的文件应该被删除，自然就爆冲突了。

分步解决方案 #

1. 准备合并基础 #

先选其中一个仓库作为合并后的目标仓库（比如选A），把B添加为远程仓库：

# 克隆A仓库（如果本地没有的话）
git clone <A仓库的URL或本地路径>
cd <A仓库目录>

# 添加B作为远程仓库
git remote add repo-b <B仓库的URL或本地路径>
git fetch repo-b

2. 给B的文件“划地盘”（关键步骤） #

因为A和B原本是互斥的，最稳妥的方式是给B的所有文件单独建一个子目录，避免直接和A的文件冲突。先去B的仓库做一次调整：

cd <B仓库目录>

# 创建子目录（比如叫b-content，名字随便取）
mkdir b-content

# 把所有文件移动到这个子目录里
# 如果你用bash，这个命令可以一次性移动除了b-content之外的所有文件
git mv !(b-content) b-content/
# 要是Windows环境，就手动选中所有文件拖进去，或者用PowerShell的移动命令

# 提交这次修改
git commit -m "Move all B content to subdirectory for merge"

回到A的仓库，重新拉取B的最新提交：

git fetch repo-b

3. 执行subtree合并 #

现在B的文件都在独立子目录里，和A的文件不会直接冲突了，执行合并命令：

git merge -s subtree repo-b/main --allow-unrelated-histories

这里--allow-unrelated-histories必须加，因为A和B删除对方文件后，Git可能会判定两者历史“无关”，不加这个参数会报错。

4. 处理剩余冲突 #

如果还有少量冲突（比如两边后来新增了同名的配置文件），手动打开冲突文件解决后，提交即可：

git add .
git commit -m "Resolve remaining merge conflicts between A and B"

可选：直接合并到根目录（谨慎操作） #

如果你确定A和B的文件现在仍然完全互斥，没有同名文件，可以跳过步骤2，直接用递归合并策略并指定优先级：

# 保留A的文件（删除B中与A重复的文件）
git merge -s recursive -X ours repo-b/main --allow-unrelated-histories

# 或者保留B的文件（删除A中与B重复的文件）
git merge -s recursive -X theirs repo-b/main --allow-unrelated-histories

⚠️ 注意：这个方式风险较高，一定要先对比两边的文件列表，确认没有重叠后再执行！

后续维护建议 #

• 合并完成后，建议把原来的A和B仓库标记为只读，所有后续开发都在新的合并仓库进行，避免重复工作。
• 可以在新仓库里更新.gitignore规则，防止不小心提交原本属于对方仓库的文件（如果有这个需求的话）。
• 如果原仓库后续还有更新需要同步，用subtree pull的方式：

  git pull -s subtree repo-b/main
  

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