Since their introduction in April 2005, both Git and Mercurial have divided opinions. Both of them have always had their supporters and die-hard fans who root for their favourite system with nearly religious enthusiasm. Thus, the discussion on developer forums often includes very subjective opinions, which makes it pretty hard to make a well-grounded decision between these two systems.
During the last few years, Git has grown to be the de-facto distributed version control system for many developers. It is safe to argue that majority of the developers on different forums vow in the name of Git, especially in the open source world. It has a huge base of users and promoters who form a truly loyal community. At the same time, Mercurial hasn’t grown in even remotely same manner but it has its supporters and it is used in many large and known corporations, such as Facebook, Mozilla, and World Wide Web Consortium (W3).
Both Mercurial and Git are distributed version control systems (DVCS). In a nutshell, a DVCS allows multiple developers to work on the same code base without constant access to the same network. All of the developers work on their own local copies (clones) of the code repository, which they then merge together after they’ve made the changes they intended. Thus, comparing Git vs Mercurial is a bit more tricky than comparing Git and Mercurial to Subversion, which is a centralised version control system.
Git and Mercurial are both also open source version control systems. This means that developers are constantly contributing to these systems by developing new features and extensions. So, if you need a certain feature in either of them, you can develop that yourself and share it with others. Or ask for somebody else to do it.
At the end of the day, both Git and Mercurial do the same thing: they keep the version history of your source code stored, so regardless your choice, you have chosen an excellent distributed version control system!
However, there are obvious differences between Git and Mercurial. A lot of the discussion revolves around the usability, required expertise, and security of the two systems. The following chapters will shed light on the most significant differences so that you’d be able of resolving your Git vs Mercurial debate.
One of the most prominent differences between Git vs Mercurial is the different level of expertise needed to use the systems. In short, Git is more complex and requires you and your team to know it inside and out before you can expect to use it in an effective and safe manner. With Git, one sloppy developer may cause major damage for the whole team. Moreover, its documentation is considered to be harder to understand. Luckily, modern code hosting platforms, such as Deveo, can prevent you from changing the history or deleting branches, which mitigates some of the risks that junior Git users might cause.
In general, if you and your team are less experienced software developers, or you have also non-technical people involved in the team, Mercurial might be the better solution. Its syntax is simpler and documentation better. Furthermore, it works as a tool should: you don’t think about it while using it, whereas with Git you might end up spending time in figuring out its unexpected behaviour and asking for help on different forums. But after you’ve learned to use Git, it offers you a lot of flexibility.
If you decide to choose Git, I encourage you to choose also an intuitive GUI. Using Git on the command line (CLI) may be a nightmare at first. The commands in Git are large and come with multiple options, which naturally increases the difficulty. Despite this, Git comes with a smaller set of commands than Mercurial, and you can always set up aliases for the Git commands. Aliases will make your Git usage a lot more pleasant.
The commands in Mercurial, to begin with, are fairly simple to learn and use. There are more of them than in Git but at the same time, they are more specific. Mercurial original developers wanted to make sure that each command does only one thing and does it well.
A peculiar thing in the Git vs Mercurial debate is that you can argue that both of them are more secure than the other without contradicting yourself. This is results from the different level of expertise required to use the systems: Mercurial is safe even for less experienced users, whereas Git offers ways to increase safety once you know what you are doing.
Mercurial doesn’t by default allow you to change history. In order to do that, you must enable it separately. Git, in turn, allows all the involved developers to change the version history. It goes without saying that this can result in huge damages. However, this also means that Git offers you a better control over history, whereas with the basic Mercurial you can only change your last commit with `hg rollback`.
Additionally, Git stores every change made for 30 days in reflog. Thus you can, for example, modify the commit message of the latest commit and revert this during those 30 days. Only locally, though, as these changes are not by default pushed to the remote repository. After 30 days the changes are garbage collected, which means that you cannot return to those afterwards.
Branching, in short, means starting a derived work with, for example source code files, you want to modify. Branches allow you to work on multiple different versions of your code at the same time, and finally merge the changes back together without breaking the code base.
One of the main reasons developers vow in the name of Git is its super effective branching model. In Git, branches are only references to a certain commit, making them very lightweight yet powerful. Branching in Mercurial has a bit different meaning than in Git. 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. So, Mercurial embeds the branches in the commits, where they are stored forever. This means that the branches cannot be removed in Mercurial because that would mean that you’d be altering the history. Thus, branching can be more cumbersome in Mercurial than in Git.
Git allows you to create, delete, and change a branch anytime without affecting the commits. If you need to test out a new feature or you find a bug, make a branch, do the changes, and delete the branch. Pretty fast, eh? However, in Mercurial, you can refer to certain commits with bookmarks and use them in a similar manner to Git’s branches.
Lastly, in Mercurial, there is a threat of pushing code to a wrong branch. Especially, if you haven’t clearly named your branches. This is easily avoidable in Git. To sum up, a major factor in the Git vs Mercurial battle is the different branching structure. It can be argued that it is better in Git than in Mercurial. Even though Mercurial may be more easy to learn and use, the branching model may cause confusion.
Git has a unique feature called staging area or index, which none of the other DVCS have. Not at least in the same sense. Staging is the practice of adding files to 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. Not everybody likes this feature, though, as it might be seen to increase complexity.
In Mercurial, there is no index or staging area before the commit. Changes will be committed as they are in the working directory. This might be an adequate and simple solution to many. If you want to have the possibility to choose the parts of the working directory that you want to commit, you can use a Mercurial extensions DirState or Mercurial Queues.
In the Git vs Mercurial debate, their support for different operating systems is often mentioned. Historically, both Git and Mercurial stem from the Linux world because originally, both of them were designed to be the version control system for the Linux Kernel project. This battle was won by Git, and Git is still highly Linux-focused. For example, it has many more GUIs on Linux than Mercurial. Mercurial on the other hand, is easy to setup also on Windows.
You can use Git also on Windows with Msysgit. However, Git might be a bit trickier to setup and use on Windows, especially if you're authenticating with an SSH key rather than a password. So, pay attention to your preferred operating system when you are choosing your distributed version control system.
This guide aims at comparing Git and Mercurial on the top-level. In other words, presenting the most distinctive differences. Fundamentally, both Git and Mercurial are very similar and tremendous version control systems. They are designed a bit differently and require different level of expertise.
Git might be more complex, harder to learn and have a fuzzier documentation. On the other hand, it is also more versatile when you’ve learned to use it and it has become the industry standard. Finding developers who are familiar with Git is easier than finding Mercurial-savvy developers. Mercurial might be easier to learn and use, and it won’t give you as many headaches as Git might. However, its branching model might be harder to grasp, there is no staging area, and it is probably not familiar to new developers when you hire them.
Despite your choice, you can count on Deveo on hosting your source code repositories!
The best way to solve the Git vs Mercurial debate is to try both. Repository management service Deveo supports both, so you can test them and decide later which suits you better! If you want to get started fast, sign up to Deveo’s cloud and set up your Git and/or Mercurial repositories with just a couple of clicks.
In the Deveo cloud, you don’t pay anything before you exceed 1GB of total storage. For additional disk space, the price is 1€/GB/month.
If you want to host the repositories on your own servers, sign up to our on-premises plan. It is free up to 5 users.