Synchronize Git repositories
将 Git 存储库与原始 SVN 存储库中的新提交同步非常容易。这为迁移流程提供了一个舒适的过渡期，您可以继续使用现有的 SVN 工作流程，但可以开始尝试 Git。
可以双向同步，但是，我们建议从 SVN 到 Git 进行单向同步。在过渡期间，您应该只提交到您的 SVN 存储库，而不是 Git 代码存储库。一旦您确信团队已经准备好进行切换，就可以完成迁移流程，并开始使用 Git 而不是 SVN 提交变更。
同时，您应该继续提交到您的 SVN 存储库，并在必要时同步您的 Git 存储库。此流程类似于转换阶段，但由于您只处理增量变更，因此效率应该高得多。
更新作者文件
我们用来将 SVN 用户名映射到全名和电子邮件地址的 authors.txt 文件对于同步流程至关重要。如果它已从我们到目前为止一直在使用的 ~/GitMigration/authors.txt 位置移出，则需要使用以下命令更新其位置：
git config svn.authorsfile 如果自上次同步（或初始克隆）以来有新开发人员承诺使用 SVN 存储库，则需要相应地更新作者文件。为此，您可以手动将新用户添加到 authors.txt，也可以使用 --authors-prog 选项，如下一节所述。
对于一次性同步，直接编辑作者文件通常更容易，但是，如果您要执行无监督同步（即在计划任务中），则首选 ---authors-prog 选项。
相关资料
如何移动完整的 Git 存储库
查看解决方案
了解 Bitbucket Cloud 的 Git
自动生成 Git 作者
如果您的作者文件不需要更新，则可以跳到下一节。
git svn 命令包含一个名为 --authors-prog 的选项，该选项指向一个自动将 SVN 用户名转换为 Git 作者的脚本。您需要配置此脚本以接受 SVN 用户名作为其唯一参数，并以 Name 的形式返回一行（就像现有作者文件的右侧一样）。如果您需要定期向项目中添加新的开发人员，则此选项可能非常有用。
如果您想使用 --authors-prog 选项，请在 ~/GitMigration 中创建一个名为 authors.sh 选项的文件。将以下行添加到 authors.sh，为在 authors.txt 中找不到的作者返回虚拟 Git 名称和电子邮件：
echo "$1 <$1@example.com>"同样，这只会根据 SVN 用户名生成虚拟名称和电子邮件，因此，如果您能提供更有意义的映射，请随时对其进行更改。
获取新的 SVN 提交
与 SVN 不同，Git 对下载上游提交和将它们集成到项目中进行了区分。前者称为"获取"，而后者可以通过合并或变基来完成。在 ~/GitMigration 目录中，运行以下命令从原始 SVN 存储库中获取任何新提交。
git svn fetch这与前一阶段的 git svn clone 命令类似，因为它只更新 Git 存储库的远程分支——本地分支还不会反映任何更新。另一方面，您的远程分支应该完全匹配您的 SVN 代码存储库的历史记录。
如果您使用的是 --authors-prog 选项，则需要将其包含在上方的命令中，如下所示：
git svn fetch --authors-prog=authors.sh与获取的提交同步
要将下载的提交应用到存储库，请运行以下命令：
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar sync-rebase这会将获取的提交重定向到您的本地分支，使它们与远程对应的提交相匹配。现在，您应该能够在 git log 输出中看到新提交。
（再次）清理 Git 代码存储库
再次运行 git-clean 脚本来删除自上次同步以来从原始 SVN 存储库中删除的所有过时标记或分支也是个好主意：
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force您的本地 Git 存储库现在应该与 SVN 存储库同步。
摘要
在此过渡期间，开发人员只提交到原始的 SVN 存储库非常重要。只有通过上面讨论的同步流程才能更新 Git 存储库。这比管理双向同步工作流程要容易得多，但它仍然允许您开始将 Git 集成到构建流程中。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Bitbucket 博客
DevOps 学习路径
