Git, Hg or Bzr — Which to recommend to a new user?

问题:

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

I have some friends that are potentially interested in learning to use a version control system for our upcoming master theses (Latex document and various programming). I'm not talking about anything huge and complicated here, just to use it for backup, looking at old revisions and some basic branching and merging.

However, I think it's a good idea to choose one that's somewhat easy to learn for a beginner. So the question is, which version control system would you recommend to someone that's new to such things to learn?

Personally I've been using Git and Mercurial a bit and at the moment I think I'm leaning towards Mercurial. I haven't tried Bazaar though.

So far this is my impressions on features suitable for new users:

Mercurial

Pros:

• Revision numbering
• Easy to checkout an old commit, work on it and merge it in
• Easy merging directly with a mergetool
• Easy branching (?)
• Nice plugins like glog

Cons:

• Branches and bookmarks can both be used for what Git calls branching - could be a bit confusing
• Doesn't give much information about what's done/wrong when a command is executed

Git

Pros:

• Full control (gives the impression of it at least)
• Detailed help and information when something goes wrong

Cons:

• Some difficult concepts (like the staging area)
• Some branching operations can be a bit difficult

Bazaar

Haven't tried it...

What do you think? Please follow the good subjective guidelines here when answering.

回答1:

The last few people I've taught revision control from scratch has been with git (including my daughter when she was about 12). I've also taught new users mercurial.

For someone with no revision control experience, both were equally easy. For someone broken by subversion or CVS, git was initially harder (though depending on their willingness to understand the fundamentals vs. blindly make things work, git was quite easy).

Based on that, and some of the other responses here and my own personal bias, I think git is the best answer. There are nearly two million git repositories on github alone. It's not going anywhere soon.

回答2:

What you assumed to be one of Mercurial pros - revision numbering - is considered to be a disadvantage by many people. And what you assumed to be git disadvantage - staging area; being difficult concept - is considered to be advantage by many people.

So this is not that simple.

But if you ask me - Mercurial is James Bond, as one of the bloggers called it - it's elegant and higher-level than git, at least on the surface. Plus its commands are pretty much like subversion commands, therefore new users who are svn converts might learn Mercurial much faster than git.

回答3:

I don't think your friends will notice a big difference with any of the three VCS. If it is just used as a simple backup with a small amount of branching (probably non-conflicting anyway), it doesn't matter which tool they choose. All three can do simple tasks without requiring the user to know any special stuff.

Especially if the people are completely new to version control, there is no real reason to choose one tool over the other. While all of them use slightly different concepts (with Git probably being the most special one), it is hardly something a new user will notice without experience with the other tools.

The distribution of your listed pros & cons (which are not really true btw) tells me that you have more or deeper experience with Mercurial than Git. As such I would recommend using Mercurial, because in the case where your friends need help, they can ask you, and you will be able to give them a good answer based on your own experience.

I think that is more important than the overall userbase in the Internet or on some help page (btw. the high amount of git questions could also mean that git is more confusing for many people – which probably is true to some amount).

Another factor on deciding on a tool for inexperienced users, especially when those might not really need it that much in their lives again, might be the availability of some easy graphical user interface. There might even be a good integration with their TeX editor, which would make them choose one tool over another.

回答4:

Recommend the one you know the best. If you're going to recommend one to your acquaintances, you should be willing to take first crack at answering their questions. Mercurial, Git, and Bazaar are all great, and vastly superior to nothing. If they ever find a deficiency, then they can try out one of the others, but honestly, for getting started, "Machts nichts!"

回答5:

I'll pass on my experience with Git and Mercurial, in both cases starting from scratch.

I decided to move my team (5 top and disciplined developers, including myself) from ClearCase (UCM, but they'd all used both base ClearCase and UCM over several years). Having looked at all 3 of Mercurial, Git and Bazaar I settled on Mercurial (influenced heavily by PEP 374).

Within a week I felt confident enough to introduce Mercurial into the team processes and people started moving over to using it. The largest difficulty was making sure I'd be able to continue to push changes upstream to ClearCase. The whole team quickly adopted it and we noticed an immediate change in the way we worked.

We used very branchy development (named branch per task) - essentially inherited from how ClearCase worked, but we found it was a good way for the team to work (note - a lot of Hg users would not like this branching strategy). A developer would work on a task and send it to someone for review. Whereas previously the reviewer would go through and make notes, etc and send them back to the original developer, with Mercurial we found we would just switch branches, review, then get the author over and make the changes together in the reviewer's environment (pair programming) and commit them to the same named branch.

All up, total time for the entire team to get up to speed (with me as mentor starting from scratch) was about 2 weeks.

My experience with Git is more recent - I only started using it about 2 months ago (and so already had considerable experience with Mercurial). However, I did start using it about 2 months ago, and I'm only now starting to feel at all comfortable with it. The biggest thing that makes me uncomfortable with Git is that Git assumes you will be editing history and makes it easy. I have to regularly read parts of the git help/manual to check that I'm doing things "right". I find the local branch + remote-tracking branch system very foreign and unintuitive, whereas branching in Mercurial is incredibly simple (to find out where you are in comparison to another repo, you just ask it).

The team I'm working with is feeling the same way. Git was decided on for the VCS, but I've now been asked to change us over to Mercurial at the end of the current phase of work.

回答6:

I like Mercurial. I am biased. I also like Perforce, but it isn't as open.

回答7:

The tags on StackOverflow should give you a pretty good indication of the community support behind it. Currently the counts of questions are:

• Git: 5,789
• Mercurial: 1,845
• Bazaar: 188

Demonstrating this in pie chart form:

Now, this shouldn't be taken as a sign that Git is more difficult to use than Mercurial, but rather that there's a lot of people asking questions about it and receiving help about. This means that if your newbies got stuck they'd have a greater chance of receiving help in the git tag than in the Bazaar tag.

I cover some of the basic git commits in my answer to "Should a developer always use version control".

Additionally, there's GitHub which is a really awesome git repository hosting site that, much like a good Red, gets exceptionally better with age. Their new file browser, for example, had me nerdgasm'ing.

In summary, I definitely think the newbies should use Git because there's a larger community of people out there using it, GitHub uses it and if they happen to use the Ruby programming language, it's effectively the de facto standard there.

回答8:

Git.

I happen to like Mercurial a lot and it was my introduction to DVCS but the reality is that Git is becoming the industry standard. When I talk to friends about what they are using at work, everyone is using Git for new projects, migrating existing projects to Git, or wishing they were able to use Git at work if they've used it for personal projects but can't get people to switch at work. Nobody talks about Mercurial or Bazaar, ever. I used to be the only person I knew who talked up Mercurial, but I jumped on the Git bandwagon as it became clear Git is what professional developers will be using for the foreseeable future. People still talk about SVN and very occasionally CVS, but that's because their projects started years ago and they haven't migrated yet, nobody talks about using them for new development.

If you guys plan to get jobs as developers after finishing your thesis, knowing the tools people actually use is in your best interest.

It's not one of your options but I just want to add that Perforce is terrible, should never have been developed, and is the most annoying and invasive VCS you can imagine.