I think that the hate that gets lumped on mercurial&#x27;s branches, though understandable, is a bit unfair<p><i>Disclaimer, it&#x27;s been years since I used hg as my primary DVCS. So some of my thoughts  here might be out of date, or have a misrecollection.<p>&gt; </i>branching in hg is pretty much broken*<p>It really isn&#x27;t. It&#x27;s absolutely not suited for the task that many people want to use it for, but it&#x27;s totally fitting with the intended use case and the &quot;history is immutable&quot; philosophy of mercurial.<p>Using mercurial branches for anything resembling feature branching is a bad idea. But mercurial branches are perfect for things like ongoing lines of development. So, for a project like PostgreSQL, you&#x27;d have a &quot;master&quot; (default) branch for the head of development and then once a release goes into maintenance mode you create a new branch for &quot;postgres-9.4&quot; and any fixes that need to be applied to that release will be made to the maintenance branch.<p>Following hg&#x27;s &quot;immutable history&quot; policy the fact that the commit was performed on a maintenance branch is tracked forever. And it should be because the purpose of your source control is to track those kinds of things: &quot;This is the branch we used for maintenance releases of version X.Y.Z, it is now closed since we no longer support that version&quot;<p>The issues with mercurial&#x27;s branches are:<p>- For a long time they were the only concept in hg that had a simple name and looked like &quot;multiple lines of development&quot;. Even though hg supported <i>multiple heads</i> and <i>multiple lightweight clones</i>, neither of those had commands or features with a clear and simple name, so they people turned to &quot;branches&quot; expecting them to do what they wanted even when they were a bad fit.<p>- &quot;branch&quot; is very general name that is often used (quite rightly) to refer to a bunch of slightly different ways of working with multiple concurrent versions. In general use it might refer simply having 2 developers who both produce independent changes from the same parent. Or to intentionally having multiple short lived lines of development based around feature. Or splitting of development right before a release so that the &quot;release branch&quot; is stable. Etc. Yet the feature in hg that is called &quot;branch&quot; is useful for only some of those things. It would have been better to call it a &quot;development line&quot; or something like that.<p>- It took far too long for hg to get a builtin way to refer to named heads (bookmarks). The model assumed that each repository (clone) would only ever want to have 1 head on each branch (development line) and that producing multiple heads was a problem that ought to be resolved as soon as possible. There&#x27;s a lot of history behind that approach (almost every CVS and SVN team I ever worked with did that), but DVCS tools made it easier to move away from that, yet official hg support lagged.<p>So even today, the &quot;branch&quot; concept in hg is only useful for a small number of cases, and the &quot;bookmarks&quot; concept is what most people want, but they&#x27;re separate things with names that don&#x27;t align with expectations.