如何在避免冲突的前提下将提交迁移至另一个GitHub仓库

核心思路是用git rebase --onto将目标提交集重新定位到目标仓库的代码基础上，逐个处理冲突的同时完整保留提交历史，比你原来的压缩方案更可控且不丢失历史信息。

具体步骤 #

1. 本地准备两个仓库的代码 #

• 克隆私有仓库repo1到本地，添加公开仓库repo2为远程源：

  git clone <repo1-url>
  cd repo1
  git remote add repo2 <repo2-url>
  git fetch repo2
  

2. 明确要迁移的提交范围 #

先确定你要迁移的70个提交的边界：

• 假设这些提交在repo1的feature-branch分支上，且是从提交X（这70个提交的前一个提交）开始到最新提交Z，那么范围是X..Z；或者直接用分支名feature-branch（如果该分支完全由这70个提交组成）。

3. 创建迁移临时分支 #

基于目标仓库的主分支（比如repo2的main）创建临时分支，用来承载迁移后的提交：

git checkout -b migrate-commits repo2/main

4. 用rebase重定位提交集 #

执行rebase --onto命令，把70个提交从原基础移到repo2的main分支上：

git rebase --onto repo2/main <X> feature-branch

• 这里<X>是你要迁移的70个提交的父提交（也就是这70个提交开始前的那个节点）；
• 如果feature-branch的所有提交都是要迁移的70个，也可以直接用git rebase --onto repo2/main repo1/main feature-branch（假设repo1的main是这70个提交的原基础）。

5. 逐步解决冲突 #

rebase过程中遇到冲突时，Git会暂停：

• 打开冲突文件，手动解决代码冲突；
• 解决后执行git add <冲突文件名>；
• 继续rebase：git rebase --continue；
• 如果某个提交的冲突实在无法处理，也可以跳过该提交：git rebase --skip（但不推荐，尽量解决）。

小技巧：如果团队协作处理冲突，可以把临时分支推到远程，每个人认领部分提交的冲突处理，或者用交互式rebase（git rebase -i repo2/main）先合并相关提交，减少冲突次数。

6. 验证与合并 #

• 迁移完成后，运行测试确保代码正常；
• 把临时分支推到目标仓库（比如repo2）：git push repo2 migrate-commits；
• 在GitHub上创建PR，合并到目标分支即可。

减少冲突的辅助策略 #

• 先同步基础变更：如果源仓库有一些不涉及核心逻辑的变更（比如依赖更新、配置调整），先手动同步到目标仓库，让两边代码基础更接近，减少后续冲突；
• 分批迁移：把70个提交分成3-4批，每批先迁移并合并到目标分支，再迁移下一批，每次处理的冲突量更小；
• 整理源提交：用交互式rebase（git rebase -i <X>）在迁移前整理源分支：合并重复修改、拆分跨文件的大提交，让每个提交的变更更聚焦，冲突更容易解决。

备选方案：如果rebase太繁琐 #

如果实在不想逐个处理提交冲突，可以优化你的压缩方案来保留关键历史：

• 把70个提交压缩成一个大提交时，用交互式rebase的squash命令，将每个原提交的哈希、标题整理到新提交的描述字段中，这样虽然丢失了独立提交节点，但至少保留了历史变更的线索。

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