Close

从 SVN 到 Git - 为迁移做准备

为什么是 Git? 部分,我们讨论了 Git 可以帮助您的团队变得更敏捷的多种方式。一旦您决定进行切换,下一步就是弄清楚如何将现有的开发工作流程迁移到 Git。

本文介绍了在将团队从 SVN 过渡到 Git 时会遇到的一些最大变化。在迁移流程中要记住的最重要的事情是 Git 不是 SVN。要充分发挥 Git 的潜力,尽力开辟新的版本控制思维方式。


对于管理员


采用 Git 可能需要几天到几个月的时间,具体取决于团队的规模。本节讨论了工程经理在培训员工使用 Git 以及将存储库从 SVN 迁移到 Git 时需要考虑的一些主要问题。

基本 Git 命令


Git 曾经以陡峭学习曲线而闻名。但是,Git 维护人员一直在稳步发布新的改进,例如合理的默认设置和上下文帮助消息,这些改进使入门流程变得更加愉快。

Atlassian 提供了一系列全面的自主进度 Git 教程,以及在线研讨会和直播培训会话。总而言之,这些教程应该为您的团队提供开始使用 Git 所需的所有培训选项。为了让您开始使用 Git,这里列出了一些基本的 Git 命令:

数据库
相关资料

如何移动完整的 Git 存储库

Bitbucket 徽标
查看解决方案

了解 Bitbucket Cloud 的 Git

Git 任务

备注

Git 命令

告诉 Git 您是谁

备注

配置作者姓名和电子邮件地址以用于提交。请注意,Git 从 user.name 中删除了一些字符(例如结尾句点)。

Git 命令

git config --global user.name "Sam Smith"git config --global user.email sam@example.com

新建本地存储库

Notes

 

Git 命令

git init

签出存储库

备注

创建本地存储库的工作副本:

Git 命令

git clone /path/to/repository

 

备注

对于远程服务器,请使用:

Git 命令

git clone username@host:/path/to/repository

添加文件

备注

将一个或多个文件添加到暂存(索引):

Git 命令

git add *

提交

备注

将变更提交到 head(但尚未提交到远程存储库):

Git 命令

git commit -m "Commit message"

 

备注

使用 git add 提交您添加的任何文件,并提交自那以后您变更过的任何文件:

Git 命令

git commit -a

推送

备注

将变更发送到远程存储库的主分支:

Git 命令

git push origin main

状态

备注

列出您已变更的文件以及仍需要添加或提交文件:

Git 命令

git status

连接到远程存储库

备注

如果您尚未将本地存储库连接到远程服务器,请添加服务器以便能够向其推送:

Git 命令

git remote add origin

 

备注

列出所有当前配置的远程存储库:

Git 命令

git remote -v

分支

备注

创建一个新分支并切换到新分支:

Git 命令

git checkout -b

 

备注

从一个分支切换到另一个分支:

Git 命令

git checkout

 

备注

列出代码存储库中的所有分支,并告诉您目前在哪个分支:

Git 命令

Git 分支

 

备注

删除功能分支:

Git 命令

git branch -d

 

备注

将分支推送到您的远程存储库,以便其他人可以使用分支:

Git 命令

git push origin

 

备注

将所有分支推送到您的远程存储库:

Git 命令

git push --all origin

 

备注

删除远程存储库上的分支:

Git 命令

git push origin :

从远程存储库更新

备注

在远程服务器上提取变更并将其合并到您的工作目录中:

Git 命令

git pull

 

备注

要将不同的分支合并到您的活动分支中:

Git 命令

git merge

 

备注

查看所有合并冲突:查看与基础文件的冲突:在合并之前预览变更:

Git 命令

git diff
git diff --base
git diff

 

备注

手动解决任何冲突后,请标记已变更的文件:

Git 命令

git add

标记

备注

您可以使用标记来标记重要的变更集,例如版本:

Git 命令

git tag 1.0.0

 

备注

CommitId 是变更集 ID 的前导字符,最多 10 个,但必须是唯一的。使用以下方法获取 ID:

Git 命令

git log

 

备注

将所有标记推送到远程存储库:

Git 命令

git push --tags origin

撤销本地变更

备注

如果您搞砸了,您可以用 HEAD 中的最后一个内容替换工作树中的变更:已经添加到索引中的变更以及新文件将保留。

Git 命令

git checkout --

 

备注

相反,要删除所有本地变更和提交,请从服务器获取最新的历史记录并将本地主分支指向它,请执行以下操作:

Git 命令

git fetch origingit reset --hard origin/main

搜索

备注

在工作目录中搜索 foo ():

Git 命令

git grep "foo()"

Git 迁移工具


有许多工具可以帮助您将现有项目从 SVN 迁移到 Git,但是在决定使用什么工具之前,您需要弄清楚自己想如何迁移代码。您的选择是:

  • 将整个代码库迁移到 Git 并完全停止使用 SVN。
  • 不要将任何现有项目迁移到 Git,而是将 Git 用于所有新项目。
  • 将一些项目迁移到 Git,同时继续将 SVN 用于其他项目。
  • 在同一个项目上同时使用 SVN 和 Git。

完全过渡到 Git 会限制开发工作流程的复杂性,因此这是首选选项。但是,在拥有数十个开发团队和可能有数百个项目的大型公司中,这并不总是可能的。在这些情况下,混合方法是更安全的选择。

您对迁移工具的选择在很大程度上取决于您选择了上述哪种策略。下面介绍一些最常用的 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 以及处理安全性和权限问题的一些常用选项。我们还介绍了开发人员在迁移流程中应准备面临的最大挑战。

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


分享此文章

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

人们通过满是工具的墙进行协作

Bitbucket 博客

Devops 示意图

DevOps 学习路径

与 Atlassian 专家一起进行 Den 功能演示

Bitbucket Cloud 与 Atlassian Open DevOps 如何协同工作

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up