Git vs. Mercurial logos
January 9, 2019

Git vs. Mercurial: How Are They Different?

Git at Scale
Version Control

Here, we cover the key differences — and similarities — between Git and Mercurial. 

What Is Git?

Git is a free distributed version control system (DVCS).

What Is Mercurial?

Mercurial is also a free DVCS tool, similar to Git.

A History of Git and Mercurial Version Control

Git and Mercurial debuted almost simultaneously in April 2005. Since then, Git and Mercurial have taken very different paths. They were both designed to replace a commercial VCS called BitKeeper. BitKeeper’s creator initially gave free licenses to Linux kernel developers, but then he changed his mind in a “mercurial” (or fickle) way. That’s where the name Mercurial comes from.

Git version control is now the most popular. It was initially promoted heavily by Linus Torvalds himself. As the pioneering Linux creator, he used to be the world’s premiere open-source advocate. And he took great pleasure in brutally criticizing every other VCS.

Mercurial hasn’t grown in the same way as Git. In 2008, the open-source community found new homes in Bitbucket and GitHub. GitHub obviously supported Git, and a lesser-known fact is that Bitbucket launched with Mercurial. Although, Bitbucket will soon end support for Mercurial

In 2011, after Atlassian acquired Bitbucket, they added support for Git repos. However, GitHub was already well-established as the home for open source. GitHub’s popularity accelerated beyond the reach of Bitbucket and Mercurial. Today, it has more than 31 million users and is owned by Microsoft. In the last decade, Git has become the standard for most development projects.

Mercurial still has a handful of large development organizations using it — including Facebook, Mozilla, and World Wide Web Consortium (W3). But it only has about 2% of the VCS market share. Comparatively, Git has more than 80%.

What Mercurial and Git Have in Common

Both Mercurial and Git are DVCS.

This allows developers to bring a repo full of code down to their workstations, perform their work items, and then put it back into a central server. Although this means you can work offline, that’s less of a concern than it used to be. (Who isn’t always online?)

Once each developer’s work is completed, it’s merged with everyone else’s work in the “dev codeline.” It gets tested, and then, at some point (hopefully sooner rather than later), it goes into production.

At the end of the day, Git and Mercurial do the same thing — they help you manage the version history of your source code. Yet there are big differences between them. 

Git vs. Mercurial: What's Different?

Here are the key differences between Git vs. Mercurial.

1. Usability: Is Git or Mercurial Easier to Use?

When comparing Git vs. Mercurial, one of the biggest differences is the level of expertise needed to use each system.

Git Is More Complex, With More Commands

Git is more complex, and it requires your team to know it inside and out before using it safely and effectively. With Git, one sloppy developer can cause major damage for the whole team. Its documentation is also harder to understand.

In general, if your team is less experienced, or if you have non-technical people on your team, Mercurial might be the better solution.

If you opt for Git, consider choosing an intuitive GUI to accompany it. Using Git on the command-line can cause nightmares, especially in the beginning. The commands in Git are long and come with multiple options, which increases the difficulty.

Mercurial Is Simpler

Mercurial’s syntax is simpler, and the documentation is easier to understand. Furthermore, it works the way a tool should — you don’t think about it while using it. Conversely, with Git, you might end up spending time figuring out finicky behavior and pouring over forums for help.

Once you get over the learning curve, Git offers teams more flexibility. 

2. Security: Is Git or Mercurial More Secure?

It seems strange, but you could argue that Git and Mercurial are each more secure than the other, and you wouldn't be contradicting yourself. Which is to say, neither of them offers the security most teams need.

Git Is Better for Experienced Users

Security in Git vs. Mercurial depends on your level of technical expertise. Mercurial may be safer for less experienced users, but Git can offer ways to enhance safety (once you know what you are doing).

Neither VCS offers the security that prevents people from accidentally or intentionally compromising code. In short, neither offers the robust security that most teams need.

Mercurial Is Safer For Less Experienced Users

By default, Mercurial doesn’t allow you to change history. However, Git allows all involved developers to change the version history. Obviously, this can have disastrous consequences. With basic Mercurial, you can only change your last commit with “hg commit – amend”.

Git also stores every change made for 30 days in reflog. For example, you can modify the commit message of the latest commit, and revert it for 30 days. However, the changes can only be made locally, as these changes are not pushed to the remote repository by default. After 30 days, the changes are collected, meaning you can no longer revert.

3. Branching: Which Branching Model Is Better?

Branching means working with files — source code — that you want to modify. Branches allow you to work on different versions of your code at the same time. Then developers can merge the changes, without (hopefully) breaking the code base.

Git’s Branching Model Is More Effective

One of the main reasons developers swear by Git is its effective branching model. In Git, branches are only references to a certain commit. This makes them lightweight yet powerful.

Git allows you to create, delete, and change a branch anytime, without affecting the commits. If you need to test a new feature or find a bug — make a branch, do the changes, and then delete the branch.

Git supports the idea of a staging area, which is also known as the index file.

Staging is the practice of adding files for your next commit. It allows you to choose which files to commit next. This is useful when you don't want to commit all changed files together.

Mercurial’s Branching Model Can Cause Confusion

Branching in Mercurial doesn't share the same meaning. This can make it more cumbersome. In Mercurial, branches refer to a linear line of consecutive changesets. Changesets (csets) refer to a complete set of changes made to a file in a repository.

Mercurial embeds the branches in the commits, where they are stored forever. This means that branches cannot be removed because that would alter the history. However, you can refer to certain commits with bookmarks, and use them in a similar manner to Git’s branches.

Lastly, Mercurial requires you take added care not to push code to the wrong branch, especially if you haven’t clearly named them. You can easily avoid this in Git.

A major differentiator between Git and Mercurial is the different branching structure. It can be argued that branching is better in Git than in Mercurial. Even though Mercurial may be easier to learn and use, its branching model often creates confusion.

In Mercurial, there is no index or staging area before the commit. Changes are committed as they are in the working directory. This might be an adequate and simple solution for many people. But if you want the option to choose which parts of the working directory you commit, you can use a Mercurial extension, such as DirState or Mercurial Queues.

Mercurial vs. Git: Which Should You Choose?

Fundamentally, Git and Mercurial are similar, and each has its merits as a VCS. They were just designed differently and require different levels of expertise.

Git has become an industry standard, which means more developers are familiar it. Mercurial's big advantage is that it’s easy to learn and use, which is useful for less-technical content contributors.

Hardly anyone uses Mercurial anymore. (But if you do, Helix TeamHub can host them.)

In the Git vs. Mercurial debate, Git is the clear choice for pure web and mobile-application development. But if you have mixed assets, large global teams, or stringent security requirements, you may want to consider another alternative.

Helix4Git helps you scale your existing Git environment. Combine this with Helix Core, and you get granular permissions and a complete change history of all digital assets – from source code to binary files. Both solutions ensure global teams get the files they need fast.

Contact us to learn more.



Want to learn more? Explore Git best practices.