如何安全地把旧仓库的 commit 历史接入新仓库 - 教程

目标：把旧仓库的提交历史“接入”到新仓库，让你在新仓库里也能看到旧仓库的 commit 记录（用于溯源、审计、排查历史难题、满足合规等）。

核心原则：不改写任何已有历史（no rebase / no filter-repo / no force push）在新仓库上创建一个“合并提交（merge commit）”，把两段互不相干的历史连接起来。就是，只

---

1. 适用场景与不适用场景

1.1 适用场景

• 旧仓库已经停止维护或只是“历史源”，新仓库是当前主线。
• 你只需要 在新仓库可追溯旧的 commit，但 不希望当前代码文件发生变化。
• 你不想做任何“重写历史”的高风险运行（避免影响协作、CI、发布、审计）。

1.2 不适用场景

• 你希望把旧仓库的代码内容也完整迁移到新仓库某个子目录，并保留每次改动的文件级别演进（这通常需要 git filter-repo / subtree / submodule 等方案）。
• 你希望把新仓库的 commit 重新排列、压缩、清洗（这不可避免会重写历史）。

---

2. 原理（为什么“接入历史”但不改变代码）

一个有向无环图（DAG）。如果两个仓库原本互不相关（没有共同祖先），你许可在新仓库上创建一个就是Git 的提交历史merge commit，让它同时拥有两个 parent：

• parent1：新仓库当前分支（例如 develop）
• parent2：旧仓库的某个分支（例如 plus/develop）

关键点在于：

• 使用 --allow-unrelated-histories 允许合并“无共同祖先”的历史。
• 使用 -s ours（ours 合并策略）让合并结果 以“当前分支内容”为准。

因此最终效果是：

• 历史接入了：图上能看到旧仓库那条历史链。
• 代码不变：合并结果的树（tree）与合并前的 tree 一致。

---

3. 操作前准备（强烈建议）

以下所有命令都在新仓库根目录执行。

• 确认当前分支正确（通常是 develop 或你们的主分支）。
• 确认工作区干净：没有未提交改动。
• 确认你有推送权限（git push 到新仓库远端）。

建议先执