分布式版本控制工具：git与Mercurial（zz）

分布式版本控制工具：git与Mercurial

[收藏此页] [打印]

 

作者：cyfdecyf  2007-12-26

内容导航：

第1页

 

【IT168 技术文档】    说到版本控制工具，很多人可能都会马上想到CVS和Subversion，但自从开始使用git以后，我在自己的开发过程中都会优先选择git而非前者。
    最早从今年初就已经开始用git。刚开始的时候的确会感到git比较复杂。一个原因是它不同于Subversion这样的集中式版本控制系统，在Subversion中只有一个仓库（repository），许多个工作目录（working copy），而像git这样的分布式版本控制系统中，每一个工作目录都包含一个完整仓库，仓库之间内容可能不相同，可以进行仓库之间的同步。另一个原因是git的命令非常之多，而它本身的概念也比较复杂（虽然 Linus说git是“stupid contenc tracker”，但其实这个东西不适合傻瓜使用），还分repository、index、working tree等，直接使用也会比较麻烦，所以实际上我一直都是使用cogito，只有必要时才直接使用git。
    为什么要使用分布式的版本控制系统？Subversion有什么不好？
    我最开始使用Subversion时一直觉得有一点很不爽，如果我想把某个已有的项目使用Subversion来进行管理，首先要建立一个仓库，然后把文件import到仓库，最后再check out，然后在check out的工作目录中进行修改。为什么要那么麻烦？我只是自己一个人进行开发而已，为什么非要有一个仓库？此其一，只是不爽而已。
    第二点使我没有办法使用Subversion、不得不寻找其他的工具的原因是，我需要在几台电脑上同时进行开发，我希望在每一台电脑上都能使用版本控制工具。所以，我需要有一个放在优盘上的仓库，这个时候使用Subversion就有问题了。一来当你提交时你必须得把优盘插上电脑，每次提交都得插上；二来仓库在优盘上的位置不能改变，否则路径改变的话使用file协议拷贝出来的工作目录就废了。我查过svn propset的帮助，似乎可以改变仓库地址，但我不会，网上也没有搜到。
    这两个问题git都可以很好的解决（严格来说我使用的是cogito）。要把已有的文件加入版本控制的话使用cg init一条命令即可。而分布式的版本控制系统解决第二个问题实在是再适合不过了。在优盘上建立一个仓库，不同机器上的仓库在开发时就尽管commit到本地的仓库好了，在要换机器之前先把修改push到优盘上的仓库，到其他机器上时pull出来，然后merge一下就好了。cogito可以直接使用update完成这两步操作。而优盘上仓库路径如果有改变的话可以使用cg-branch-chg很方便地修改远程仓库的地址。实际上可以认为优盘上的仓库就是一个中央仓库，所以有许多个仓库其实并不是一件可怕的事情，完全可以像使用集中式的版本控制系统那样自定一个为中央仓库即可。但分布式的版本控制系统不强制你这么做，给你更多的灵活性。
    更加让我喜欢git的是它的branch概念。我在使用Subversion的时候从来没有用过，因为它的branch概念是通过copy来实现的（当然不是实际的拷贝），不够直观。目前我只用branch来进行实验性的开发。而Linus使用git管理内核开发时通过branch 整合多人所做的修改，内核有那么多的branch，Linus通过git可以很轻松的merge这些不同的branch所做的修改，最后从他自己的仓库中发布新版本的Linux内核。
    此外，git对磁盘空间的利用也更高效（不过需要定期对仓库使用git repack -d命令），其他方面性能也都很出色。想想它要管理Linux内核那么大的项目就可以知道了。
    Linus在Google Tech Talk上做过git的介绍，以及他是如何使用git来管理内核开发的。他的演讲里面对分布式版本控制系统的好处有更好的说明。不过Linus自己也承认自己是个“strong opinion person”，他在演讲的时候多次说集中式的版本控制系统没有前途，因此，Subversion的开发者想要开发一个更好的CVS其实是脑子出了毛病，实在是太“offensive”了。好在他是Linus，大家都知道他的个性。
    但是，但是……git很好，可它不跨平台，至少在非Linux平台上运行得没有那么好，在非Linux文件系统上会有麻烦。虽然我不在Windows上做开发，但是最近要在Solaris上做开发，我不想花时间在Solaris上把git装起来，而且如果以后要和其他使用Windows的人合作，我可不想再使用Subversion。所以，我需要一个替代git的工具。
    这篇文章介绍了Mozilla“移向”新版本控制工具时是如何做出选择。（原文强调是“move”而不是“pick”，因为最后的候选者都很好。）首先肯定要用分布式的，然后在4个分布式的版本控制工具中筛选，git和Monotone因为支持平台问题而被排除，剩下Bazaar和Mercurial。前者有 Canonicol在支持。而后者已经是OpenSolaris等著名项目的版本控制工具，而且有着非常完善的文档，可以很方便地使用Python的Web Server发布项目。在Mozilla的版本控制工具选择中，Mercurial最终因为性能而胜出。所以，我也决定转到Mercurial，看了看文档，感觉和cogito很像，比git更简单，迁移过程应该会比较顺利。
    另外提一下，分布式的版本控制工具还有darcs，arch。前者是用Haskell编写，后者据说很复杂。