2011-02-13 posted in [点滴技术] with tags: [技术, git, mercurial, SCM, and svn]
两类版本控制工具简单说明
这三种版本控制工具，我都有用过，目前项目中使用最多的是
Mercurial, 而一些自己的项目也分布在
Github (
Git )或者
Bitbucket (
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的一次更新），所以成本则显得很低，后续的更新成本也相对较低。
当然，分布式版本控制工具下的代码库在线上时，如果需要恢复到某个特定版本，则无需网络通信即可完成，而集中式的 版本控制工具则成本相对较高。
总之，如果二进制文件的大小较小、版本更新频率较低，则选择二者差别不大，对于二进制文件较大、版本更新频率较多的 代码库，则选择集中式版本控制工具更为高效。
