如何将现有git提交rebase到由旧.tar.gz归档构建的历史提交之上

冲突原因 #

你遇到的冲突是因为两个独立初始化的Git仓库没有共同祖先提交，Git无法识别historical仓库的最后一个.tar.gz对应提交，和new仓库的初始提交内容完全一致，直接执行git rebase historical时会尝试将两个无关联的根提交做三向合并，自然会出现大面积文件冲突。

前置验证（必做） #

先确认两个仓库的基准提交内容完全一致，避免后续做无用功：

• 在historical仓库主分支执行 git rev-parse HEAD: ，得到根目录树哈希值
• 在new仓库执行 git log --reverse --oneline 找到第一个初始提交的ID，执行 git rev-parse <new仓库初始提交ID>:
• 如果两个哈希值完全一致，说明基准内容匹配，可以继续后续操作。

正确迁移操作（两种方案任选即可） #

方案1：使用git rebase --onto（推荐，操作最快） #

该命令可以明确指定迁移的提交范围和新的基准，绕过无共同祖先的问题：

1. 在new仓库中拉取historical仓库的提交记录：

git fetch historical

2. 确认要迁移的提交范围：找到new仓库的初始提交ID（也就是和historical最后一个提交内容一致的那个提交，记为INIT_COMMIT）
3. 执行rebase命令，将INIT_COMMIT之后的所有提交迁移到historical主分支顶端：

git rebase --onto historical/main <INIT_COMMIT>

举个例子：如果new仓库初始提交ID是ghi789，命令就是git rebase --onto historical/main ghi789，Git会自动跳过初始提交，只把你后续的修改提交移动到historical分支顶端，因为基准内容完全一致，不会出现大面积冲突。

4. 如果过程中出现少量冲突，正常编辑冲突文件解决后，执行git add .，再执行git rebase --continue即可。

方案2：使用补丁导出导入（更稳定，适合提交数不多的场景） #

1. 在new仓库导出所有修改补丁：

git format-patch <INIT_COMMIT> -o /tmp/project-patches

该命令会把初始提交之后的所有提交，按顺序导出为单独的补丁文件存入/tmp/project-patches目录

2. 切换到historical仓库的主分支，批量应用补丁：

git am /tmp/project-patches/*.patch

3. 若遇到补丁应用冲突，解决冲突后执行git add .，再执行git am --continue即可。

后续操作 #

迁移完成后验证最终代码内容和你原来new仓库的顶端提交内容一致，确认无误后就可以直接推送到GitHub的公开仓库。

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