为什么选择git作为版本管理工具

团队组建已经半年有余，也该写一些东西了。

团队最初搭建的时候，有很多的东西是必须确定的，比如版本管理工具等。这些东西一旦定下来，要么以后就完全改不了，要么就是变更的代价非常大，所以必须慎重。这里就说一下为什么我们选择git。

选择一个好的版本管理工具是可以达到事半功倍的作用的。因为自信团队成员的能力不弱，所以在学习门槛的高度上就没有做太多的思考，不会自学好了。结合团队情况，考虑的角度有

SVN

• 熟悉程度：★★★★☆
  SVN在IT界至少有将近十年的历史了吧，所以大家都比较熟悉
• 操作系统支持程度：★★★★★
  老牌劲旅，各个系统的支持程度非常没问题
• 客户端支持程度：★★★
  在Mac上没有看到非常好用的，Versions 貌似很好用，但是收费，所以也没用。至于乌龟SVN，那就更别说了。
• 离线操作能力：☆
  鉴于我对SVN的理解，这就别提了，一个矬字了得。
• 并行开发能力： ★★★
  团队上八成的功能都是可以分开进行的，所以相互之间干扰不会太大。但是SVN的合并功能啊，能让武大郎蹦起来打飞机。
• 对运维的支持能力：★
  因为团队中是通过跳板机到生产环节，所以SVN是无法直接把代码输送到线上的，只能通过打包等方式。
• 扩展能力：☆
  我完全不会嘛
• 综合评分：★★★
  从这分数也就意味着基本上跟SVN拜拜了

Mercurial（hg）

• 熟悉程度：★★★★☆
  从上一个团队开始，我们就深度使用hg，所以对hg是非常的熟悉，而且我个人非常认同hg保留一切历史的哲学。
• 操作系统支持程度：★★★★★
  Python作品，对各个系统的支持均非常赞
• 客户端支持程度：★★★★
  在之前，Mac上有MacHG，这是一个非常好用的客户端。而且在合并的时候可以使用P4Merge，这也是非常赞的。
• 离线操作能力：★★★★★
  hg作为一个分布式版本管理系统，离线能力必然不在话下。
• 并行开发能力： ★★★★
  结合我写的hgflow，hg的并行开发能力是没有问题的。但是由于hg哲学的问题他会保留一切历史，比如我本地的feature也会保留，但是这些都是没用的，而且会随着历史的演进不断的积累，会成为项目的垃圾累赘。
• 对运维的支持能力：★★★★
  可以在跳板机上增加一个临时的repo，实现代码对生产环节的推送。
• 扩展能力：★★★★★
  直接用Python扩展，我的hgflow就是一个标准的扩展程序。而且我熟悉嘛。
• 综合评分：★★★★
  主要还是不断增加的历史垃圾给hg减了一星

git

• 熟悉程度：★★★☆
  因为有hg的经验，所以git也会熟悉的比较快，但是一些高级的命令还不是很熟悉。
• 操作系统支持程度：★★★☆
  win总是git的一个痛，不过我们不在win上开发，所以这个并不是大问题
• 客户端支持程度：★★★★☆
  其实一直没找到一个非常好用的客户端，但好在git的命令行非常方便，而且团队觉得这无所谓。而后来发现了 SourceTree 这个应用，这是我见过的最完美的git/hg客户端，而且1.5版之后还支持git-flow/hg-flow。
• 离线操作能力：★★★★★
  这就别说了嘛
• 并行开发能力： ★★★★★
  git的哲学对并行开发支持非常赞，而且这是他出现的主要目的。
• 对运维的支持能力：★★★★
  和hg处理方式几乎一样。
• 扩展能力：☆
  这个我也完全不会，但是git的扩展现在非常完备，所以也应该不用自己开发。
• 综合评分：★★★★☆
  git看来是最好的选择，尤其是 SourceTree 的出现。

总所上述，我们决定选择git作为我们的版本控制软件，不会的大家多学学即可。

另，再次推荐 SourceTree ，天然的支持 git-flow/hg-flow，社区支持 github/bitbucket，所以用起来非常的爽。而且结合P4Merge，基本上解决了我遇到的所有问题。而且 SourceTree 是免费的，只要申请一个免费的 License 即可。