Git vs. Mercurial vs. Subversion

Git vs. Mercurial vs. Subversion

两类版本控制工具简单说明

这三种版本控制工具，我都有用过，目前项目中使用最多的是 Mercurial, 而一些自己的项目也分布在 Github ( Git )或者 Bitb****et ( Mercurial )上。

比较而言， Git 和 Mercurial 是一类版本控制工具，即分布式的版本控制工具， 而 Subversion 是集中式的版本控制工具，如果用一句话来概括二类的不同，则 为： 使用分布式版本控制工具检出的版本，包含完整的版本、历史等与代码 相关的信息，而集中式的版本控制工具检出的版本，通常只包含最新的一个版本 的代码 ， 所以分布式版本控制工具能够极大地减少网络通信（如与服务器）， 大大地提高效率。一个简单的例子例如要查看一个文件的log，用 Subversion 时就得和集中 的服务器通信来获得，获取的延时取决于网络通信等因素，而 Git 或者 Mercurial 则 只是一个本地的操作。

下面简单对比了下二类版本控制工具的优势：

	分布式版本控制工具	集中式版本控制工具
优点	减少网络通信 去中心化，提高可靠性 更利于分布式协作 生产率(productivity)相对较高	单次检出的成本低 较适合二进制文件（相比） 掌握的人更多 命令流程简单 相关配套软件成熟（如IDE集成）
缺点	首次检出代码时代价高 不适合二进制文件 掌握的人较少 命令流程相对复杂 相关配套软件不成熟	大量的网络通信 可靠性较低（信赖于中心结点） 不太利于分布式开发

三种常用版本控制工具的命令对比

据说，IT行业跳槽率是很高的一个行业，特别是开发人员，面对一个新的公司、新的同事、新的开发环境、 新的版本控制工具等的机率是很高的，而一个有较高素养的开发人员，应该对于主流的版本控制工具有一定 的了解，特别是对于常用的一些基本操作有能够较熟练的掌握。下面，我就简单总结下不同的操作目标下 三种不同工具的具体操作方式和命令。

	Subversion	Mercurial	Git
检出新的代码库	svn co repos_path wc	hg clone repos_path wc	git clone repos_path wc
更新已有的代码库	svn up	hg pull -u	git pull
查看本地的修改	svn st	hg st	git status
提交本地的修改	svn add files svn ci -m “comments”	hg add files hg ci -m “comments” hg push	1.git add files 2.git commit -m “comments” -a 3.git push
查看log	svn log file	hg log file	git log file
恢复某个文件到某个版本	svn merge -c -REV file	hg revert -rREV file	git checkout REV file
恢复整个代码库到某个版本	svn up -rREV	hg up -rREV	git checkout REV
比较文件	svn diff -rREV:REV file	hg diff -rREV:REV file	git -rREV:REV file

当然上面只是最最基本的使用说明，不过大致已经涵盖了开发人员90%以上的日常操作，诸如branch,tag等应用， 你大体上可以通过”svn/hg/git help”来获得信息。

当然倘若你能够熟练地掌握其中之一，那也自成为你的瑞士军刀。

关于二进制文件的版本控制

当然通常你会说没有这个必要来将二进制文件纳入到版本控制之中，我们大可选择ftp等覆盖方式来完成。 在实际的开发中，我们也有类似的方法，例如flash生成的二进制文件的swf和音乐文件mp3等，前者我们 还是使用 Mercurial 而后者我通常就使用 scp 等命令来完成了覆盖。

这时候，分布式版本控制工具的劣势就显现出来了，因为二进制文件每次更新基本上是一个完全新文件的更新， 而非增量，举个例子，假设一个分布式版本控制工具（ Git /Mercurial)的代码库中只有一个10M的swf文件， 那么经过100个版本更新后，大小大致为10*100M=1G(大约，同样假设每次更新后的新文件大小也为10M）。如此一来， 当我们在服务器上部署时，首次的网络通信成本就非常巨大！记得在我们实际的一次项目经历中，一次更新了2个小时才 完成了更新。当然后续的更新相对成本较低。

同样的例子，如果改为使用 Subversion ，中心结点（服务器）上的代码库的大小大致也是1G左右，但是当我们部署时， 只需要大致10M左右的网络通信即可（取版本号为100的一次更新），所以成本则显得很低，后续的更新成本也相对较低。

当然，分布式版本控制工具下的代码库在线上时，如果需要恢复到某个特定版本，则无需网络通信即可完成，而集中式的 版本控制工具则成本相对较高。

总之，如果二进制文件的大小较小、版本更新频率较低，则选择二者差别不大，对于二进制文件较大、版本更新频率较多的 代码库，则选择集中式版本控制工具更为高效。

常用的代码hosting服务

这三类代码控制工具都有很好的第三方的hosting解决方案，下面只列举最常用的几个：

1. Bitb****et (针对 Mercurial , 支持免费private repos)
2. Google Code (针对 Subversion 和 Mercurial , 不支持免费private repos)
3. Github (针对 Git , 不支持免费private repos)

现在应该说发展比较好的是 Github, 大家不妨可注册一个玩玩。

相关的链接

1. git magic
2. svn book
3. mercurial guide
4. git tag on SO (相关的对比和分析）