Git vs. Mercurial: How Are They Different?
Mercurial and Git are both used for version control. But what are the key differences? What are the similarities? Here we compare Mercurial vs. Git.
What Is Mercurial?
Mercurial is a free distributed version control system. It's also referred to as a revision control system or Mercurial source control. Mercurial is used by software development teams to manage and track changes across projects.
Mercurial launched in 2005. But it's popularity has since faded. It 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.
What Is Git?
Git is a free distributed version control system (DVCS).
Git also launched in 2005. In the last decade, Git has become the standard for most development projects. Git has more than 80% of market share.
What Mercurial and Git Have in Common
Both Mercurial and 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: Is Mercurial Better Than Git?
The biggest difference between Mercurial vs. Git is the 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.
Here's a breakdown of all of 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: Is Mercurial vs. Git 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.
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.
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.
Keep Your Mercurial Repo?
Some teams using Mercurial choose to host their repositories. But some tools — like Atlassian's Bitbucket — are discontinuing support for these repositories. The good news is you can host in Helix TeamHub (if you want to keep it in Mercurial).
Switch to a Better Version Control
Git and Mercurial can be great version control options. But if your team and files are growing in size and complexity, these solutions might not be enough. The same is true if security is important to your team.
Sound familiar? Then it might be time to switch to a better version control — Helix Core.
Helix Core is easy to use. (See how Helix Core's P4 commands compare to Git commands or Mercurial commands.) It provides stronger security options (including MFA, access control, and more) than Git or Mercurial. And it offers a better way to branch and merge (Perforce Streams).
See for yourself why Helix Core might be the best choice for your team. You can get started for free for up to 5 users.