git 2.9+ 默认拒绝合并无共同祖先的历史，需用 --allow-unrelated-histories 显式允许；若要将项目a作为子目录合并进b，应配合 -s subtree 使用，并可通过 git remote remove 清理临时远程引用。
git merge 报错 fatal: refusing to merge unrelated histories
这是 Git 2.9+ 的默认行为，不是 bug，是保护机制。当你尝试把两个完全没有共同祖先的仓库（比如各自从空初始化、或从不同远程克隆）用 git merge 合并时，Git 会直接拒绝。
根本原因是：Git 默认只信任「有共同祖先」的分支合并，避免意外把两套完全无关的提交历史强行缝在一起，导致日志混乱、diff 失效、bisect 失效等问题。
解决方法就是显式告诉 Git：“我知道它们不相关，但我要合并”——靠 --allow-unrelated-histories 参数。
- 必须在
git merge命令末尾加上--allow-unrelated-histories，不能写成--allow-unrelated-history（少 s 就报错） - 这个参数只影响本次 merge，不影响后续操作，也不改变仓库配置
- 如果合并后发现文件冲突特别多（比如所有文件都被标为“added by us”和“added by them”），说明两个仓库确实结构重叠严重，得手动处理路径或先重命名子目录
把项目 A 的代码作为子目录合并进项目 B
直接 git merge --allow-unrelated-histories 会把 A 的所有文件平铺到 B 的根目录，大概率覆盖或冲突。更合理的做法是先让 A 的内容进 B 的某个子路径（比如 legacy-a/），再 merge。
实操分三步：
- 在项目 B 中，用
git remote add a-repo <path-to-a></path-to-a>添加 A 为远程（可以是本地路径，不用真推到服务器） - 执行
git fetch a-repo拉取 A 的全部提交，此时它的分支叫a-repo/main（或a-repo/master） - 运行
git merge -s subtree --allow-unrelated-histories a-repo/main，注意必须加-s subtree，否则还是平铺
这样 A 的历史会被保留，且所有文件自动移到子目录下。后续还能用 git subtree pull/push 和 A 保持同步（如果需要）。
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
合并后怎么删掉无关的远程引用
git remote add 只是本地配置，不会上传到你自己的远端。但留着容易混淆，尤其当多个临时仓库反复 merge 时。
删掉很简单：
- 用
git remote remove a-repo清理远程别名 - 用
git branch -r | grep a-repo确认是否还有残留的远程分支引用 - 如有，用
git update-ref -d refs/remotes/a-repo/main（或对应分支名）手动删掉引用（git remote prune不管这种本地添加的 remote）
不清理也不会出错，但下次 git branch -a 会看到一堆 a-repo/* 分支，干扰判断。
为什么不用 git subtree add 或 git submodule
这两个是替代方案，但和 merge --allow-unrelated-histories 解决的问题不同：
-
git subtree add是单向导入快照，不保留完整历史（除非加--squash以外的选项，但麻烦）；而merge --allow-unrelated-histories完整带入提交树，适合长期整合 -
git submodule是引用关系，A 仍是独立仓库，B 里只存一个 commit hash；一旦你希望把 A 的代码真正“吸收”进 B 的开发流，submodule 就不合适了 - 如果只是临时搬几段代码，用
cp -r+git add更轻量；只有当你明确要保留 A 的全部提交作者、时间、message，并让它成为 B 历史一部分时，才值得走 merge 流程
最容易被忽略的是：合并后，git log --oneline 会同时显示两个原始项目的提交，但默认不展示它们来自哪个分支。如果想快速区分，建议在 merge 提交的 message 里手写注明来源，比如 “Merge legacy-a v1.2.0 — unrelated histories”。
