将特定的 SVN 分支迁移到 GIT（2018 年迁移的主干）答案

【问题标题】：Migrating specific SVN branches to GIT (trunk migrated in 2018)将特定的 SVN 分支迁移到 GIT（2018 年迁移的主干）
【发布时间】：2021-09-24 07:01:02
【问题描述】：

我有一个 SVN 存储库，在 2018 年的某个时候部分迁移到了 GIT（Bitbucket）。 SVN 和 GIT 存储库都在使用中。在 SVN 方面，主要是旧项目的分支。 GIT 存储库用于主干/主控开发。现在我被要求将剩余的分支从 SVN 迁移到 GIT。问题是我不知道原始转换是如何完成的（完成此操作的人离开了公司）。我可以轻松地将 SVN 存储库转换为 GIT，但我永远无法使其处于提交 ID 实际匹配的状态。目前，让我最接近的方法似乎是

git svn clone -T trunk URL --no-minimize-url --no-metadata -r1:10 --preserve-empty-dirs

我只在几个版本中使用了 -r，所以它更快。作者实际上收到了相同的电子邮件（name@UUID），并且 UUID 与 2018 年转换的 git repo 匹配。问题似乎是 SVN 历史记录以 2 个仅包含文件夹和提交消息的提交开始 - 这些提交对我来说被忽略了，但不知何故，对于较旧的迁移，它们导致 git 提交只包含消息。

例子：

svn

commit A: create dir 1

commit B: create dir 2

commit C: create some files in dir 1 and 2

原始 git 迁移结果：

commit A: commit message only

commit B: commit message only

commit C: create some files in dir 1 and 2

我目前使用 git svn 的努力：

commit C: create some files in dir 1 and 2

尝试使用 SubGit：

subgit import --trunk trunk --username user --svn-url URL)

commit A: commit message only (modified with notes)

commit B: commit message only (modified with notes)

commit C: create some files in dir 1 and 2 (commit message modified with notes)

关于 SubGit 的注释 - 这种方法非常接近（基于文档，我很确定我可以修复提交消息）。对我来说问题是，如果我不提供作者文件而不是以“user@uuid”结尾，我最终会以“user@localdomain”结尾。可能的解决方法是提供从原始迁移中导出作者并将其作为作者文件提供？

有人对如何做到这一点有任何建议吗？如果我无法在 git 端获得相同的提交 id，如果我能找到共同的祖先（即使 id 不匹配），是否有一些“合并”两个 git repos 的理智方法？

【问题讨论】：

标签： git svn migration git-svn

【解决方案1】：

这是 SubGit 的默认行为——如果它没有给出作者映射（或者如果没有找到与 SVN 用户名匹配的情况），那么它会使用 SVN 用户名和默认域（设置通过 core.defaultDomain SubGit 配置设置或default-domain 命令选项）。因此，如果您需要 SubGit 为给定的提交设置特定的 Git 用户身份，那么为它提供作者映射文件确实更好。如果可以使用“authors-file”命令选项来完成（可能你知道，但仍然:)）

subgit import --trunk trunk --username user --authors-file <AUTHORS_FILE_PATH> --svn-url URL

我没有完全理解提交消息有什么问题，假设 Git 中的提交消息与 SVN 中的不匹配？如果是，那么这也可以使用 SubGit，但不能使用 subgit import one-liner，它需要导入初步配置和配置文件编辑。因此，首先运行以下命令来准备一个 Git 存储库以供导入：

subgit configure --snv-url URL <GIT_REPO>

其中 GIT_REPO 是用于导入的新 Git 存储库的路径。准备好存储库后，编辑 GIT_REPO/subgit/config 文件，如果需要，设置 core.defaultDomain 和 core.authorsFile，在 [svn] 部分设置正确的映射，并使用 svn.gitCommitMessage 设置配置所需的提交消息，这里有一个有关此设置的更多详细信息：

https://subgit.com/documentation/config-options.html#svn.gitCommitMessage

配置文件设置好后，可以用短命令开始导入：

subgit import GIT_REPO

关于 Git 提交注释——SubGit 总是创建注释，但它们不影响提交 SHA1，因此不需要对注释执行任何操作。顺便提一下，作者和提交消息并不是唯一可能影响提交 SHA1 的设置，还有像“svn.excludePath”或“translate.createEmptyGitCommits”这样的设置。

【讨论】：

【解决方案2】：

您可能会考虑创建一个 单独的 svn repo 克隆，从您要克隆的最旧分支开始的修订之前的修订开始，并且您只克隆您关心的分支。 ... 然后您可以将这些修订移动到其他分支所在的另一个 git 存储库（使用补丁或使用可以访问两个 git 存储库作为远程的存储库）....如果您使用与基础相同的修订版，git 应用来自新克隆的修订版应该没有任何问题......而且我接受我过于简单化了很多，你可能会遇到一些极端情况，但基本逻辑是声音。

【讨论】：