1

I really like the Hg Flow for Mercurial repositories. we are currently using Bitbucket, and in each product multiple developers are working. basically they can work as below:

  • a team might work on a single feature.
  • another team might work on a release/hot fix.

So do i keep the "develop" branch in BitBucket or local repositories. and how about feature branches, should i push them to the central repository and remove when required. i assume we should do so right?

Thanks

Aneef
  • 3,641
  • 10
  • 43
  • 67
  • I think this answered my question:http://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task – Aneef Oct 07 '13 at 12:18
  • 1
    How can that answer your question? You question is about mercurial, that other question is about git. Branching is fundamentally different between both. – JonnyJD Oct 09 '13 at 18:20
  • @JonnyJD do you have any suggestions? – Aneef Oct 13 '13 at 07:41
  • Well, I didn't want to write an answer, since I am more of a git user than hg, but I can sum up a bit why I think there are different considerations for hg in this case. – JonnyJD Oct 13 '13 at 09:21

1 Answers1

2

I personally neither use git flow or hg flow as tools, but I do use some of the methods for my own projects (manually).

Before going into detail, you always need to provide branches in the main/bitbucket repository when multiple people need to merge or branch from them. This definately includes "develop" and probably also features/fixes multiple people need to work on (unless you have another repository or method to exchange branches/commits between them)

The difference between using git and mercurial/hg is relevant here, since the branching models are quite different. See A Guide to Branching in Mercurial for details. Using hg bookmarks would be quite similar to what git does with branches, but there is no full support for the bookmark branching model on BitBucket (see this ticket).

hg flow (the tool) uses named branches. In contrast to git branches, these are not at all light-weight, but permanent and global (they can at least be closed now). This means whenever any commit created on any (named) branch other than "default" is pushed to bitbucket (even after merging) this will create the branch in the bitbucket repository.

So you don't have any other choice than keeping all branches in the main repository. However, You can decide when to push and when to close these. I would advise using hg push -r to push only the branches/heads you want to push and only pushing these when they are either needed by somebody else or finished and merged. Branches should be closed as soon they are not needed anymore. (This is probably done by hg flow automatically) You should close branches locally whenever possible. This way they might not even appear in the bitbucket interface. Some might reach the bitbucket repository only in closed state (which hides them from the interface).

Obviously you should often push any branches multiple people need to merge from. In my understanding of the workflow the "develop" branch is always exactly one branch per project that should be pushed frequently (after local testing).

In case you are either not using hg-flow or named branches things are a bit different. Both, using forks/clones or bookmarks as a branching method doesn't generate permanent or necessarily global branches.

Like mentioned above, you can't use bookmarks (reliably) when you also want to use bitbucket pull requests. You have to push bookmarks separately. A normal push will only update (a head of) the branch so you might miss commits from other team members when marging later. Hg will tell you when a new head is created. In that case you might want to merge the branch with the remote bookmark into your branch before pushing.

When using forks as branches it works a bit like with bookmarks, but bitbucket has full support for that. You need to have a new fork on bitbucket for every branch. You naturally only want to create extra forks if you need different people to work on it and you don't have other means of commit exchange for them. You will need at least a separate "develop" repository then.

I personally wouldn't use the full "flow" with hg on bitbucket. For my projects the "develop" branch is the same as master/default, since I don't roll out releases with git (other than development builds, that wouldn't use the release branch anyways). I don't need a separate "production" branch, since tags can mostly be used for production usage. I also don't create a separate "release-preparation" branch. There is only a point in time when I only apply bugfixes on develop and stop merging features. That obviously won't work when you need to work at the same time on features that are dependendant on features not to be released in the next release.

Always using the full "git flow" is easy because git branching is easy and light-weight. Depending on the branching model you use and how supportive the other tools are, using the full "hg flow" might not be "worth it".

The hg guide actually discourages use of named branches for short-lived branches. See Feature separation through named branches. The "easy" branching concept promoted in the guide is forking/cloning. Bookmarks would be the natural way to translate git flow if the tool/bitbucket support would be better (and bookmarks longer a core hg feature).

Disclaimer: I prefer git when I can choose. I do use hg, but not as my personal choice.

You also might have considered most of this, but since you didn't state any of these details and accept an answer (in the comments) that is quite different to what you are asking, I wanted to elaborate a bit.

Edit:

To follow-up on the comments:

I think hg bookmarks are comparable to git branches because both are just movable pointers to commits. The main difference is, that when you delete a branch in git, the commits are possibly lost (when not part of other branches or pointed to in a another branch before they are garbage collected). When you delete a bookmark in hg, then the commits are still part of the repository (part of the (named or default) branch) unless manually stripped.

Anonymous heads are related, but only as something the bookmarks point to. Without bookmarks pointing to them the anonymous heads are not usable as a branch to work with (for more than just a local merge) and share. When you have anonymous heads in a repository you don't know what they are supposed to be or where they came from, unless you remember or have other clues. In my eyes anonymous heads are only a workaround for late implementation of bookmarks and no good implementation of remotes/remote heads.

Named branches are rather unrelated, as the only thing they have in common with git branches is having a name. They are light-weight in comparision to cloning the whole repository (forking as branch model), but not in terms of "you can't get rid of them". They are permanent. Most places tell you not to use named branches unless you have a very good reason or it is a long-running branch.

JonnyJD
  • 2,593
  • 1
  • 28
  • 44
  • Hg's bookmark is not as similar to git-style branch as you suggest. Bookmark branch is something in btw anonymous branch and named branch. The only difference is that it has a tentative name (as opposed to anonymous branch, which has no name, and named branch, which has a permanent unremovable name). At the fundamental level, they are all the same: If you merge a bookmark branch to the main branch, all changesets in the former will become part of the latter. This is very different from git, where the main branch doesn't contain any history of the merged branch (which is a bad or good thing). –  Oct 14 '13 at 13:23
  • Also, named branch is not at all as heavyweight as you suggest, either. –  Oct 14 '13 at 13:24
  • The main point about named branches is that they are permanent (which is "heavyweight" in my eyse, but obviously not to others. – JonnyJD Oct 14 '13 at 15:34
  • anonymous branch (= default), anonymous head (= head without tip or bookmark pointing to it) and named branch (= non-default branch) don't have much to do with bookmarks. A bookmark can be on the default or a named branch (a difference git doesn't have). A head with a bookmark on it is not anonymous anymore. – JonnyJD Oct 14 '13 at 15:38
  • Git does **not** lose the history of the merged branch unless you rebase everything. It's just that the name of the branch is not saved with the commits. – JonnyJD Oct 14 '13 at 15:39
  • Just some clarification of concepts: What I mean by anonymous branch is one that has no bm nor its own name, and it shares the same name as the parent branch, which can be either the default or a named branch. Per http://mercurial.selenic.com/wiki/BranchingExplained: Light-weight branches are completely separate branches inside one common repository. They are quite cheap with respect to space requirements... My point is bookmark branch is fundamentally different from git-style branch. And it is as light-/heavy-weight as named/anonymous branch. –  Oct 14 '13 at 21:35
  • One thing that is explained well in http://mercurial.selenic.com/wiki/BranchingExplained is that you should almost never use named branches. – JonnyJD Oct 15 '13 at 11:57
  • But apart from that I don't think your link is a good introduction to branching models. Not for hg and especially not for git. It mixes up use cases and branching models. "short term branches" and "implicit (unnamed) branches" are both using the branching model of "multiple (anonymous) heads in one (named or default) branch". Both are used as short-term branching just to get a merge done. Both are not suitable as actual branches to work with and share (without merging right away). – JonnyJD Oct 15 '13 at 12:14
  • As of bookmarks vs. git branches: Both are just movable pointers to a commit. The difference is, that in git commits that are not pointed to are almost like "not there", for sure not permanent. In hg these "unnamed heads" are easier to find and always part of the branch, but also not of much use. Git ("light-weight") branches don't really care if they point to commits that are part of other branches or not. This is the same for bookmarks. So these can be separate branches, but don't have to be. – JonnyJD Oct 15 '13 at 12:15
  • I somewhat agree that bookmarks are as light/heavy as anonymous branches, because they are just pointers to these. Named branches are not, since the name is permanent. Apart from that, nothing is really light-weight in hg, since it all involves commits that are permanently part of a repository (unless manually stripped). When you delete a branch in git, everything is "gone". The name and if not part of other branches also the commits (though retrievable by pointing another branch at them, until garbage collected). – JonnyJD Oct 15 '13 at 12:16
  • You have a very different concept of light-/heavy-weightness. –  Oct 15 '13 at 17:59
  • Also, bookmark branches and git branches are not just pointers. By branches, we really mean the lineage of the revision history, not just something that labels the lineage. The difference between bm branch and git branch is deeper than that at the label level. –  Oct 15 '13 at 18:04
  • Of course the lineage is important, but without anything that points to it or names it, this isn't a complete branching concept. Of course the lineage itself is different in hg and git, even when using bookmarks. My point is just that using bookmarks you come closest to the git branching model. – JonnyJD Oct 15 '13 at 23:18
  • I disagree on your first statement:"with anything that points to.., this isn't a complete branching concept". Anonymous branch is obviously a counterexample of that. You noted for git "when you delete a branch in git, everything is gone", that's correct. But for hg you need also realize that deleting bm/named/anonymous branch after merging is totally impossible. That's the fundamental difference btw git and hg branches. The similarity in having a name and/or the life time of the name is superficial. –  Oct 16 '13 at 00:45
  • So you are saying using anonymous heads for a (hg) workflow is fine and there is only a superficial difference between using bookmarks, named branches and anonymous heads? Good luck. – JonnyJD Oct 16 '13 at 14:20
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/39368/discussion-between-schrodingers-cat-and-jonnyjd) –  Oct 16 '13 at 16:26
  • Comment on the followup: 1. hg's bookmark corresponds *merely* to the name of git-branch. The concept of branch refers to the lineage of the revision history. This is something totally different from the concept of name/bookmark. The two concepts should NOT be confused. The implementation of the branch concept is fundamentally different in hg from in git. And this implementation is the SAME for anonymous, named, bookmark branches in hg. 2. The concept of weightness has nothing to do with the persistency of the branch name, but instead to the duplication of the repo. –  Oct 17 '13 at 13:37