Git vs. Mercurial: How Are They Different?
How are Git and Mercurial different? Our goal is to explain the similarities and differences between two version control systems (VCS) — Git and Mercurial.
Since their almost simultaneous debuts in the open source world in April 2005, 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.
The History of Git and Mercurial
Since then, Git has steadily grown as the most popular VCS. 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. 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.
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%.
Git vs. Mercurial: What’s the Same?
Both Mercurial and are .
DVCS 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. When discussing the differences between Git vs. Mercurial, the conversation tends to revolve around usability, required expertise, and security.
Ease of Use — Mercurial Is Simpler
When comparing Git vs. Mercurial, one of the prominent differences is the level of expertise needed to use each system. 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.
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.
Git Has More Commands, and They’re More Specific
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.
Git vs. Mercurial Security
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.
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.
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.
The Branching Model in Git vs. Mercurial
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
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.
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.
Getting Code Ready in Git, aka Index file
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.
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.
Git vs. Mercurial: Which Do You Choose?
Fundamentally, Git and Mercurial are similar, and each has its merits as a version control system. 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. 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.