如何批量迁移git-svn提交至非关联Git仓库？

没问题，这种场景下用git rebase --onto是最适合的方案——因为两个仓库共享同一个发布标签的内容（虽然历史无关联），我们可以基于这个共同的内容基础，把git-svn里的补丁提交批量“移植”过来，避免全量冲突。具体步骤如下：

1. 准备工作：确认标签内容一致性 #

首先要确保两个仓库里的目标发布标签内容完全一致，这是后续无冲突重放的核心前提：

• 在仓库2中添加git-svn仓库作为远程并拉取内容：

  git remote add git-svn-repo <你的git-svn仓库URL>
  git fetch git-svn-repo
  

• 对比两个仓库中标签的内容：

  # 查看仓库2中标签的提交ID
  git rev-parse <release-tag-name>
  # 查看git-svn仓库中对应标签的提交ID
  git rev-parse git-svn-repo/<release-tag-name>
  # 对比两者内容，无输出则说明完全一致
  git diff <release-tag-name> git-svn-repo/<release-tag-name>
  

2. 创建目标补丁分支 #

在仓库2中，基于发布标签创建要接收补丁的分支：

git checkout -b patch-branch <release-tag-name>

3. 批量重放补丁提交 #

使用git rebase --onto命令，把git-svn仓库支持分支上的所有补丁提交（即发布标签之后的提交）重放到新创建的patch-branch上：

# 语法：git rebase --onto <目标分支> <起始提交（不包含）> <要重放的分支>
git rebase --onto patch-branch git-svn-repo/<release-tag-name> git-svn-repo/<support-branch-name>

这个命令的作用是：把git-svn-repo/support-branch-name中所有在git-svn-repo/<release-tag-name>之后的提交，逐个应用到当前的patch-branch上。

4. 处理少量冲突（如果有） #

因为两个仓库的标签内容一致，大部分提交应该能自动应用。如果遇到冲突，Git会暂停rebase过程：

• 打开冲突文件，手动解决冲突（只需要处理提交中实际修改的部分，不会出现全量文件冲突）
• 标记冲突文件已解决：git add <冲突文件名>
• 继续rebase：git rebase --continue
  重复这个过程直到所有提交重放完成。

5. 验证并推送 #

重放完成后，检查提交历史是否符合预期：

git log --oneline --graph patch-branch

确认无误后，推送到仓库2的远程：

git push origin patch-branch

额外注意事项 #

• 如果git-svn的支持分支包含合并提交，可添加--preserve-merges参数保留合并结构，但如果是线性提交的话不需要
• 操作前建议给仓库2做一个备份分支（比如git checkout -b patch-branch-backup <release-tag-name>），以防操作失误

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