UPDATE Jan 2021: Looking for the latest updates on version control systems? Read our most recent post on VCS:
Your 2021 Crash Course in Version Control Systems
Mercurial and Git are two of the most popular distributed version control systems. But which of them is better, and why? This is an age-old argument, with gazillions of forum posts of software developers arguing their case, offering pros and cons on both.
That is because their feature sets are so similar, yet their strengths and weaknesses make them ideal for different use cases. Read on for a list of pros and cons for both Git and Mercurial!
Find out why advanced software engineering teams use codeBeamer ALM!
Mercurial in a nutshell
Mercurial, also known as Hg, is a free VCS (version control system) that promises high performance and scalability for distributed teams. As per user reviews, Mercurial is considered a monolithic system that's not as flexible as Git. On the upside, it is easy to use, and doesn't let developers edit previous commits. That's a handy lack of capability in areas such as safety-critical product delivery, where strict regulatory requirements necessitate transparency and full change control.
While it has its limitations, using Mercurial is way easier than Git, and users of Subversion will find it easy to transition over to Mercurial. This tool also has better documentation, so should you have any issues using Mercurial, you're sure to find an answer to your question soon.
User opinions about Git
Based on forum discussions, it is clear that Git is more complex in every sense of the word. In particular, Git's data model (repository format) and the command line syntax as well as the help documentation – none of it is easy to understand. Most commands lead to further commands, and simple actions can require complex actions to undo or refine. That said, all this complexity translates to more flexibility: once you know how to use it, Git can be fully configured to suit your processes and work environment.
Git also offers superior capabilities around branching, tagging, and merging, something well appreciated by large distributed teams working on complex products. As mentioned above, users' ability to go back and edit the history of commits is a double-edged sword that requires a careful process approach.
The decision about whether to use Git on a development project is primarily a question of how knowledgeable and experienced your team is with Git. A single weak link can bring down the entire team. The obvious example of this is seen in Git's version control: it is, simply put, unsafe and prone to accidental alteration by users (potentially affecting the entire team). Therefore, a minimum level of solid knowledge is necessary, and Git's subpar documentation doesn't help you all that much.
Git puts control firmly in the hands of your project manager (or whoever is maintaining the codebase). The problem with this is that the majority of Git users are coders (contributors) and what they need most of all is a clean interface. This is where Git fails to deliver, putting functionality over usability, and favoring the PM over the contributor.
Git vs Mercurial
When comparing Git to Mercurial, there are a couple of important points to note:
- Both Git and Mercurial's way of handling history is essentially just a directed acyclic graph. However, Mercurial provides you with a simple linear history that can cause confusion. Git, on the other hand, enables you to follow the history backwards, but it is complicated and can get hard to follow.
- Git is often believed to handle branches better than Mercurial. Git's branch structure helps you avoid merging code in the wrong place.
- Git enforces technical excellence. Simply put, if you are not a Git expert, it's probably a good idea to use Mercurial or get some training before starting to work with Git.
- Git is more powerful for larger projects. One good example of its superior feature set is “partial checkouts”.
- When migrating from Subversion, you might want to consider that switching to Mercurial is relatively easy and straightforward, while transitioning to Git requires way more effort (not to mention all the training necessary for your team).
- A quick fact that you might find interesting: Git dominates the market with about 80% penetration whereas Mercurial's share is at around 2%.
codeBeamer ALM supports both Git and Mercurial, and in addition to version control, it provides a powerful toolset to support digital product development across the entire lifecycle. Try this integrated Application Lifecycle Management platform free for 30 days, or contact us with your questions!
