从 Subversion 过渡到 Git

/ 版本控制 / 没有评论 / 1535浏览

目前,想从 Subversion 过渡到 Git 其实并不困难,只要你不把 Git 和 Subversion混淆就行。一旦你明白了两者在概念上的区别,这个改变的过程就会变得容易。

-----------------来自小马哥的故事

分布式与集中式

Subversion是一个集中式(centralized)的版本控制系统。所有的开发团队成员都工作在单一的远程中央仓库上,当在这个中央仓库上进行 “签出(checkout)” 操作时,它就会在你的本地计算机上设置一个 “工作副本(working copy)”。这就是一个存储在你本地计算机上的一个特定版本的快照。

alt

Git从 Subversion过渡到GitGit是一个分部式(distributed)的版本控制系统,它有着一个不同的工作方式。相对于Subversion 的 “签出(checkout)”,每一个Git用户会从远程仓库“克隆(clone)”出一个本地仓库。反过来说,一个用户会得到一个完整的仓库,而不仅仅只是一个工作副本。用户在本地计算机上拥有自己的仓库,并且包含所有的项目历史记录。用户可以在自己的本地计算机上做任何想要操作,例如提交(commit),历史检查(inspect history),恢复到一个旧的版本等等。只有当你想要共享你的工作结果时,你才需要连接到远程服务器上。

仓库结构和 URLs

一个 Subversion 的仓库通常都是由几个目录组织起来的。“trunk” 目录对应你的开发主线,“branches” 目录对应那些特定的工作背景下的开发,而 “tags” 目录则用来标记一个特定的版本。它们都要通过自己的 URL 来指向到它在中央仓库中的具体位置:

svn+ssh://svn@example.com/svn/trunkGit

仓库就完全不一样了,它的组成完全就是一个在项目根目录下的 “.git” 文件夹。对分支和标记的查找完全依靠命令,而不是通过 URLs。Git 的 URL 只指向仓库的位置。

ssh://git@example.com/path/to/git-repo.git

分支

正如刚才提到的, Subversion 的分支仅仅是一些有特殊含义的目录。在创建一个新的分支时,你只是把项目的当前状态完完整整地拷贝到这个新的分支目录中。

Git 的分支技术是它的设计核心,因此它拥有一个完全不同的概念。一个在 Git 中的分支就是一个指向一个特定版本的指针:不拷贝任何文件;不创建任何目录;没有任何额外的操作。在 Git 中你永远工作在一个分支上,至少工作在那个系统默认创建的 “master” 分支上。在你的工作副本上只包括你当前的活动分支中的文件( Git 称之为 “HEAD”)。所有其他的版本和分支都被保存在你的本地仓库中,并且随时都可以非常快速地恢复到一个旧的版本。一定要记住 Git 的分布式特性:分支可以被发布到在远程服务器上,但是本地上的分支对于日常的工作更加重要。

提交

提交在 Git 中就是完全另外一种情况:

分享工作

在 Subversion 中,在提交之后,你的工作会被自动地转移到中央仓库上去。只有在你连接到这个中央服务器时你才可以进行提交。

不会自动上传任何东西。你可以自己决定,你的那些分支(也可能是所有分支)需要共享给你其他的团队成员。除此之外共享工作也是十分安全的。冲突只会出现在你的本地上,它决不可能发生在远程服务器上。这会让你有信心来解决冲突,因为你不会破坏远程仓库。

为什么选择 Git

虽然市场上有几十种不同的版本控制系统,一些世界上最著名的项目(例如 Linux 内核,Ruby on Rails,或是jQuery)都选择了使用 Git 作为它们的版本控制系统。为什么它们都选择 Git 呢?

节省时间Git

运行快速。尽管我们在这里讨论的只是运行一个命令所需要的几秒钟,但是把它累积在你的日常工作中就是一个不小的飞跃了。它可以节省那些不必要的等待时间,并且去完成其它一些有意义的工作。

离线工作

当你不能联机远程中央仓库时你该怎么工作呢?对于一个像 Subversion 或者 CVS 的集中式版本控制系统来说,如果你没有连接到中央仓库,你就不能很好的工作。如果使用 Git ,几乎所有的东西都可以简单地在你的本地机器上完成。例如进行提交,查看你的项目历史,合并或者创建分支等等。至于在哪里工作?什么时候工作? Git 不会给你施加任何限制。

撤销错误操作

每个人都会犯错,而使用 Git 的最大好处就在于,几乎在所有的情况下你都能 “撤消” 你的错误操作。比如如果你忘记了把一个小小的改动包含进来,因此你要改正你的上个提交。又或者你想要撤销一个完整的提交,因为这个功能有可能是不必要的。当发生了很严重的错误时,你甚至可以通过恢复引用日志来让一个提交不可见。你可以放心,Git 几乎很少真正地删除数据。

可靠性高

不用担忧,你不会在 Git 中搞砸任何东西,这种感觉是不是非常好?在你的 Git 项目中的每一个团队成员都克隆了整个项目在他们的本地计算机,这个本地克隆也可以看作一个完整的项目备份。除此之外, Git 上的操作几乎都是进行数据添加,几乎从不删除数据。这意味着丢失数据或是仓库损坏的情况几乎不可能发生。

让提交更有意义

只有包含了相关的改动的提交才有意义。想象一下,如果一个提交中包括一个新添加的功能 A,还包括功能 B 的一部分改动,并且还存在一个对错误 C 的修复。这样其他的团队成员就很难理解这个提交的意图,而且当其中的一个改动出现了错误,撤销起来也非常麻烦。利用它独一无二的 “暂存区(staging area)” 概念,Git 可以帮助你打造很细微和精准的提交。你可以准确地判断哪些更改将被包含在你的下一个提交中,即使只是一行改动。Git 真正提高了对版本控制的实用性。

更高的自由度

当使用 Git 工作时,你可以定义一个对项目和团队有意义的工作流程。使用 Git 也不需要其它的要求。你可以连接多个远程仓库,使用 rebase 来替代合并,或者在需要时可以使用子模块。当然,你也可以简单地像 Subversion 那样仅仅使用一个远程的集中式仓库。无论你使用什么样的工作流程,它都有各种各样的优点。

避免混乱

关注点分离可以更明确地了解事情的进程。当你工作在功能 A 上时,不应该有任何人受到你未完成的代码的影响。如果那个功能是完全没有必要的话呢?或是完成了对它的一些改动提交后,你注意到你完全错了呢?分支功能就可以解决这些问题。当然其他版本控制系统也都有分支,但是 Git 真正的把它改进地更快速,更简单了。

顺应潮流

聪明的开发人员应该顺应潮流。Git 正在被越来越多的知名公司和开源项目所使用,如 RubyOn Rails,jQuery,Perl,Debian,Linux 内核等等。拥有一个大型的用户群体是一个很大优势,因为往往会存在很多系统去推动他的发展。大量的教程,工具和服务,这让Git更加具有吸引力。