Git Vs Mercurial hg? 异地协同开发，分布式SCM方案选择！

最近有项目需要多人在异地协同开发，用什么来做配置管理呢？
当然，分布式的版本控制系统是首选，目前比较流行的有两个，Git和Mercurial（hg）,为了比较决策，在网上搜了下，在Windows下开发的话，觉得hg更方便点，尤其是有tortoiseHG,异地共享更简单，当然，是指针对人数不多的团队，不是太大的项目，没有考虑性能问题。否则，可能还是Git有优势，想想看Linus的作品，目前用来管理Linux Kernel的开发，自然就明白了。

当然，mercurial也不是不行，python的开发就是用mercurial在管理，具体谁更好就不讨论了，关键是对我而言，哪个更加好用，简便才是硬道理！

觉得最方便的就是在于TortoiseHG集成了WEB Server,这样，在同步的时候，只要简单地从右键菜单上启动web Server,就可以把repository 发布出来，的确够方便吧？

show 下图片：



启动后是这样的：

当然，在启动前，你还可以把相关的参数配置一下，仔细研究下，里面的东西不少。


ps: 今天打开看了下，阅读量一夜之间就有了不少，谢谢大家的关注，想想应该补充下内容，以对得起大家的时间。

如果，你的机器在防火墙后，或者是没有公共的域名，使用WEB Serve的方式就有些不方便。当然，有不少的免费域名可以通过3322.org或者花生壳申请账号，并通过客户端使用。配置工作稍微麻烦点，这里就不写了，有兴趣的朋友可以参考下其他网上的说明。

在这里要补充的是一个利用邮件来共享repository的途径。

还是看图说话，写个简要的梗概，具体的细节部分需要大家亲自试一下才能体会得到。
1. 配置好邮箱设置


2. 发送变更

注：邮件中也可以发送patch,只是用文件附在邮件内容中，需要手工再处理下，不推荐。
如果只是在交流沟通时用倒也方便，仅是看看，不实际合并时比较好。

3. 协作者从邮件附件中获得：


相对而言，Git在windows上的GUI就简陋了些，尤其是没有简便的web发布功能令它逊色好多---对我这个实用的懒人而言，呵呵。尽管我用Git比HG早:)

相对于这个GUI界面而言，个人觉得bash的命令行界面还更灵活些，在Linux平台下，一些插件也使工作更加轻松和有效率。

附图是MinGW下的Git Bash使用界面，包含有命令自动完成，帮助使用等，也还算比较方便。




附： 这是另外一个人的意见，英文的，就不翻译了。 

当然，他也有他的道理----兼听则明，自己根据实际需要选择合适的才是最重要的，毕竟，有助于轻松完成项目才是最重要的。

Git vs Mercurial - Why I chose git

Background and Our Needs

I first heard about distributed version control systems from Allan Odgaard on the TextMate blog. We’ve been working for about a year on Unison, which is a web application to develop online training. Our development has been so fast-paced at times we’ve been forced to push out releases more quickly than we could test them thoroughly. More than once we’ve needed to push out a less-than-stable feature for a high-profile client. We would later realize something wrong with the feature, but there was no way to go back.Branching and reverting changes in version control software is supposed to allow you to do these things, but both are so annoying in SVN that we never actually used either. We only kept a branch around when we wanted to make a release and continue development in the trunk. We would never have dared roll back any commits

Enter Distributed Version Control

Distributed Version Control promised to solve these problems for us. We would be able to branch as often as we liked, which would then allow us to keep branches around for longer without worrying about merging them later.

I first looked at git, then tried mercurial (hg) for awhile, then finally decided on git. I’m going to try to provide an unbiased review of some of their strengths and weaknesses.

Realize that both tools are good at merging, both have strong user communities, and they are very similar choices. I found good comparisons hard to come by.

Mercurial

Mercurial has several advantages over git.
Excellent Documentation: The hgbook helped me to understand the concepts
Cleaner Commands: The interface requires fewer options and flags
Intuitive Commands: The names they picked for reverting changes make more sense
Windows Support: They have a full windows client, although using it to make lots of branches would get crazy fast
It also has some disadvantages
“Named Branches” suck: They added this feature as an afterthought. The way everyone branches is by “cloning” a repository. So, if you want to work in a new branch, you have to make a brand new copy of everything. The implementation of named branches simply isn’t workable
Rewriting History is difficult: hg doesn’t have the features git does here

Git

Git has its own strengths
Branching is Supreme: This is a big one. Git lets you make new branches at any time, and lets you switch back and forth between them in one working copy.
Remote Branches: Git can send and receive changes from several different public repositories. This is useful if you need to publish more than one branch so others can download your changes.
Merging and Rewriting History: You can squash several commits together into one big commit when you merge, getting rid of the useless messages. You can easily pull a new version of the code you’re working on into your experimental branches.
Disadvantages
Slightly more confusing: There are more commands by default, and the reverting commands are hard to keep straight at first

The Wrapup

The interface to Mercurial is easier, and I like their mainstream approach, but git is simply far better with anything advanced. I don’t feel that Mercurial can handle making branches for each feature you are developing, and doesn’t do a good job of pushing/pulling changes from public repositories.

In the end, we picked Git. I’m going to revisit mercurial in another year and see if they’ve finished adding a few more necessary features. I wanted a DVCS in the first place so I could branch like crazy, and Mercurial really doesn’t support it well enough.

<!--/entry-content-->

Posted in Environs.

其实，从DVCS本身来讲，我也倾向于Git,它的功能更加完善，可能有些命令不是那么直接，不太容易理解，也比较多。但考虑到一个众多志愿者参与的项目，像Linux Kernel这样的集市式的开发项目，Git作为一个目前来讲近乎理想的方案的确为Linux的快速发展起到了很大的作用，并且，它是Linus在长期的BitKeeper使用经验的基础上开发的，无论从需求把握的角度，还是从它的性能方面的设计考虑都有很多过人之处。

就我本人的经验而言，从开始做软件开发到现在，也有将近10个年头了，经历过几个公司，也参与过不少的大的项目，使用过几种商业的、或是开源的VCS，不少是被动接受的，后来自己选择，决策用什么，算是有些经验，但总体来讲，这些VCS是各有千秋，适用才是最好的。

从接触的先后顺序来说，依次使用过VSS、CVS、ClearCase、Perforce、SVN、Git,前段时间才听说HG，觉得不错，现在为了新的项目，临时学了下，总体来讲，一般在局域网环境中使用的话，我还是喜欢CVS，毕竟，这是个大家都熟悉的工具，简单易用，也不必再为了这个工具来专门花时间来培训团队人员，否则在使用过程造成的麻烦可能会带来些不必要的开销。 但在异地开发、或者是项目比较大，各部分难以齐头并进的时候，DVCS系统才是更好的选择，另外一种应该选用DVCS的情况是，当项目需要严格的对外发布版本控制时，选择DVCS可以让各小组内部先保证小范围的集成顺利进行，这样可以避免在用集中式版本控制系统时，在deadline前，出现大家同时提交，冲突不断，拼命加班的情形。

如果，团队成员学习能力都比较强，建议在局域网内开发时，也选择用Git这样的DVCS,毕竟，个人习惯不一样，每个人的开发速度也不同，Git强大的分支管理和历史记录回溯功能，可以为项目进展提供强大的灵活性，也肯定会提高整体的开发效率。

相信，以后的版本管理中，类似Git的工具将会成为主流，Git也会变得更加简便易用的。