从 SVN 到 Git - 为迁移做准备

Atlassian 的迁移脚本

如果您有兴趣迅速过渡到 Git，那么 Atlassian 的迁移脚本对您来说是个不错的选择。这些脚本提供了将现有 SVN 存储库可靠地转换为 Git 存储库所需的所有工具。由此产生的 Native-Git 历史记录可确保您在转换流程结束后无需处理任何 SVN 到 Git 的互操作性问题。

我们已经提供了完整的技术演练，介绍如何使用这些脚本将整个代码库转换为 Git 存储库集合。本演练解释了从提取 SVN 作者信息到重新组织非标准 SVN 存储库结构的所有内容。

SVN Mirror for Stash（现为 Bitbucket）插件

SVN Mirror for StashSVN Mirror for Stash 是一个 Bitbucket 插件，可以让您轻松维护一个可同时使用 SVN 和 Git 的混合代码库。与 Atlassian 的迁移脚本不同，SVN Mirror for Stash 允许您随心所欲地在同一个项目上同时使用 Git 和 SVN。

对于大型公司来说，这种折衷解决方案是一个不错的选择。它允许不同的团队在方便时迁移工作流程，从而实现逐步采用 Git。

什么是 Git-SVN？

git-svn 工具是本地 Git 存储库和远程 SVN 存储库之间的接口。Git-svn 允许开发人员使用 Git 在本地编写代码和创建提交，然后将它们推送到具有 svn 提交样式行为的中央 SVN 存储库。这应该是暂时的，但是在讨论从 SVN 切换到 Git 时很有用。

如果您不确定要切换到 Git，想让一些开发人员在不提交全面迁移的情况下探索 Git 命令，那么 git svn 是个不错的选择。它也非常适合培训阶段——无需突然过渡，在担心协作工作流程之前，您的团队可以使用本地 Git 命令轻松进入培训阶段。

请注意，git svn 应该只是迁移流程中的一个临时阶段。由于它仍然依赖 SVN 作为“后端”，因此它无法利用更强大的 Git 功能，例如分支或高级协作工作流程。

推广策略

迁移您的代码库只是采用 Git 的一个方面。您还需要考虑如何将 Git 介绍给代码库背后的人。外部顾问、内部 Git 支持者和试点团队是将开发团队迁移到 Git 的三种主要策略。

外部 Git 顾问

Git 顾问基本上可以为您处理迁移流程，但只收取象征性的费用。这样做的好处是可以创建一个非常适合您的团队的 Git 工作流程，而无需花时间自己搞清楚。在您的团队学习 Git 时，它还为您提供了专家培训资源。在 SVN 到 Git 迁移方面，Atlassian 合作伙伴是专业人士，也是寻找 Git 顾问的好资源。

另一方面，自己设计和实现 Git 工作流程是团队了解新开发流程内部工作原理的好方法。这样可以避免顾问离开时您的团队陷入困境的风险。

内部 Git 拥护者

Git 拥护者是您公司内部对开始使用 Git 感到兴奋的开发人员。对于具有强大的开发人员文化且拥有渴望成为早期采用者的程序员的公司来说，利用 Git 拥护者是一个不错的选择。这个想法是让您的工程师成为 Git 专家，这样他们就可以为您的公司设计一个量身定制的 Git 工作流程，并在需要将团队的其他成员过渡到 Git 时担任内部顾问。

与外部顾问相比，这种方法的优势在于将您的 Git 专业知识留在内部。但是，训练 Git 拥护者需要投入更多时间，而且有选择错误的 Git 工作流程或实现不当的风险。

试点团队

过渡到 Git 的第三个选择是在试点团队中对其进行测试。如果您有一个小团队在处理一个相对孤立的项目，这种方法效果最好。如果将外部顾问与试点团队中的内部 Git 拥护者相结合，形成最佳组合，这样效果会更好。

这样做的好处是需要整个团队的支持，同时也限制了选择错误工作流程的风险，因为它在设计新的开发流程时会得到整个团队的意见。换句话说，它可以确保比顾问或拥护者自己设计新工作流程时更快发现任何丢失的部分。

另一方面，使用试点团队意味着更多的初始培训和设置时间：不是一个开发人员想出新的工作流程，而是整个团队在适应新工作流程的同时可能会暂时降低工作效率。但是，这种短期的痛苦绝对能带来长期收益。

安全性和权限

访问控制是 Git 的一个方面，您需要从根本上重新考虑如何管理您的代码库。

在 SVN 中，您通常将整个代码库存储在单个中央存储库中，然后按文件夹限制不同的团队或个人的访问权限。在 Git 中，这是不可能的：开发人员必须检索整个存储库才能使用它。您通常无法像使用 SVN 那样检索存储库的子集。权限只能授予整个 Git 存储库。

这意味着您必须将大型单体 SVN 存储库拆分成几个小型 Git 存储库。实际上，当我们的 Jira 开发团队迁移到 Git 时，我们在 Atlassian 亲身经历了这种情况。我们所有的 Jira 插件过去都存储在单个 SVN 存储库中，但是迁移后，每个插件最终都存储在自己的存储库中。

请记住，Git 旨在安全地整合来自数千名独立 Linux 开发人员的代码，因此它确实提供了一些方法来设置团队需要的任何类型的访问控制。但是，这可能需要重新审视您的构建周期。

如果您担心在新的 Git 存储库集合之间保持依赖关系，您可能会发现 Git 上的依赖关系管理层很有用。依赖关系管理层将有助于缩短构建时间，因为随着项目的发展，您需要“缓存”以加快构建时间。在 “Git 和项目依赖关系” 这篇实用文章中可以找到每个技术堆栈的推荐依赖关系管理层工具列表。

适合每个开发人员的存储库

作为开发人员，您需要适应的最大变化是 Git 的分布式特性。不是一个单一的中央存储库，而是每个开发人员都有自己的整个存储库的副本。这极大地改变了您与其他程序员合作的方式。

您使用 git clone 将整个 Git 存储库克隆到本地计算机上，而不是使用 svn checkout 签出 SVN 存储库并获取工作副本。

协作是通过使用 git push、git fetch 或 git pull 在存储库之间移动分支来实现的。在 Git 中，共享通常在分支级别完成，但也可以在提交级别上完成，与 SVN 类似。但是在 Git 中，提交代表的是整个项目的整个状态，而不是文件修改。既然您可以在 Git 和 SVN 中使用分支，这里的重要区别在于您可以使用 Git 在本地提交，而无需共享您的工作。这使您可以更自由地进行实验，更有效地脱机工作，并加快几乎所有与版本控制相关的命令的速度。

但是，重要的是要明白，远程存储库不是指向他人存储库的直接链接。它只是一个书签，可防止您每次与远程存储库交互时都必须重新键入完整的 URL。除非您明确将分支拉入或推送到远程存储库，否则您要在隔离的环境中工作。

对于 SVN 用户来说，另一个重大调整是“本地”和“远程”存储库的概念。本地存储库位于您的本地计算机上，所有其他存储库被称为远程存储库。远程存储库的主要目的是让团队的其他成员可以访问您的代码，因此不会在其中进行积极的开发。本地存储库位于您的本地计算机上，这是您进行所有软件开发的地方。

不要害怕分支或合并

在 SVN 中，您可以通过编辑工作副本中的文件来提交代码，然后运行 svn commit 将代码发送到中央存储库。然后，其他人可以使用 svn update 将这些变更拉取到自己的工作副本中。SVN 分支通常是为项目的大型、长时间运行部分保留的，因为合并是一个危险的过程，有可能破坏项目。

Git 的基本开发工作流程有很大不同，不受单一开发线（例如 trunk/）的束缚，而是围绕分支和合并展开。

当您想在 Git 中开始处理任何内容时，可以使用 git checkout -b 创建并签出一个新分支。这为您提供了一条专门的开发线路，您可以在其中编写代码，而不必担心会影响团队中的其他任何人。如果您损坏了无法修复的内容，只需用 git branch-d 把分支丢掉即可。如果您构建了一些有用的内容，您可以提交一个拉取请求，要求将其合并到 main 分支中。

潜在的 Git 工作流程

选择 Git 工作流程时，重要的是要考虑团队的需求。简单的工作流程可以最大限度地提高开发速度和灵活性，而更复杂的工作流程可以确保更好的一致性和对正在进行的工作的控制。您可以调整和组合下面列出的通用方法，以满足您的需求和团队中的不同角色。例如，核心开发人员可能使用功能分支，而承包商则使用克隆。

• 集中式工作流程可提供与常见 SVN 流程最接近的匹配，因此这是一个不错的入门选择。
• 基于这个想法，使用功能分支工作流程可以让开发人员隔离正在进行的工作并保护重要的共享分支。功能分支也是通过拉取请求管理变更的基础。
• Gitflow 工作流程是功能分支更正式、结构化的扩展，是明确定义发布周期的大型团队的绝佳选择。
• 最后，如果您需要最大限度的隔离和对变更的控制，或者有许多开发人员为一个存储库做贡献，可以考虑使用克隆工作流程。

但是，如果您真的想作为一个专业团队充分利用 Git，您应该考虑功能分支工作流程。这是一个真正的分布式工作流程，高度安全，可扩展性极强，并且具有典型的敏捷性。

将您的团队过渡到 Git 可能是一项艰巨的任务，但事实并非如此。本文介绍了迁移现有代码库、向开发团队部署 Git 以及处理安全性和权限问题的一些常用选项。我们还介绍了开发人员在迁移流程中应准备面临的最大挑战。

希望您现在已经为将分布式开发引入公司奠定了坚实的基础，无论其规模或当前的开发实践如何。