We are in a situation where the customer has requested an urgent deployment of the current features we are working on. These features are being developed in a mercurial branch named 'sprint 1' for arguments sake.

We also need to start working on the next sprint whilst the customer undertakes UAT. If they report any issues, we need to fix them on the 'sprint 1' branch and eventually redeploy them. Meanwhile, the rest of the team is supposed to be working on the 'sprint 2' features.

Would I just start a 'sprint 2' branch from the tip of the 'sprint 1' branch as soon as we go in to UAT?

  • Could you describe your branching model and workflow that you are currently using? The 'branch from the tip of another branch' is something that tends to send up warning flags to me and suggests other problems may be lurking just under the surface with other workflows.
    – user40980
    Oct 30 '15 at 0:04
  • To be totally honest, this is our first foray in to branching. We previously just developed directly off the default branch. But as we've picked up bigger projects, we've quickly realised that it isn't feasible
    – link64
    Oct 30 '15 at 0:25

The flow of the system of old was basically everyone commits to the master / main / trunk / default or whatever, and at some point something is built from a specific revision. This works well for small projects, but starts to have difficulty (as you noticed) when you start trying to go in different directions at the same time.

So, you branched for the 'sprint 1' for the role of 'bug fixes and stabilization of issues in sprint 1'. And now you've got sprint 2 that is coming up... and where should that branch be made?

Before going too far, lets delve a bit into philosophy of version control.

Each branch has one or more roles and a policy that is determined when it is branched.

Even if you don't think about it, it is the case. Even if you are working on the 'everyone submits to the master,' it is the case. I'm going to name these roles:

  • mainline
  • development
  • maintenance
  • accumulation
  • packaging

Well, I didn't name them. I stole borrowed them from one of my variate documents on branching: Advanced SCM Branching Strategies

When you are doing the 'everything on master', master has all these roles. And thats ok.

The idea of a policy comes from Branching Patterns for Parallel Software Development and the policy branch. This suggests if the policy of the branch needs to change to facilitate work there should be a new branch. For example, if the policy on /trunk is "it must build successfully at all times" and in order to do some development, some work in progress check-ins are needed, that is a branch based on a change of policy.

Whenever one of those roles changes, or you need a subset of the roles, merge and or branch.

You've branched for 'sprint 1'. This has the role of development and packaging. Thats ok. But it isn't mainline. And that is where all branches should have as a parent or grand parent (or great grand parent) and where all code should eventually end up.

Branching from 'sprint 1' to 'sprint 2' means that the code for 'sprint 1' didn't make it back into the mainline. It should.

Ideally, you would branch for 'sprint 1' from mainline, work on it, and when work is complete, merge it back to the mainline. You can do that merge back to the mainline multiple times.

With 'sprint 2', it branches from the mainline, and work is done on it. As changes from 'sprint 1' go into the mainline, they get merged from the mainline into 'sprint 2'.

There's a better way of doing this

Back in 2010, there was a blog post about a model for git branching that tried to put some order into the branches. It was A successful Git branching model and has come to be known as 'git flow'

git flow

The 'master' branch is the one that git users tend to have as the mainline in many non-git flow cases. Its not here. Master is the tagged releases.

The mainline is the yellow one - develop. All branches eventually merge to develop.

Your sprint would be one or more feature branches (thats one way of looking at it) and once the features in it get merged to develop, a release branch is made from develop. That branch has the role of packaging - and the bug fixes are done on it and moved out to the master tagged releases and then back into develop - the mainline.

And wile thats all and good, you're using hg. So, here's hg flow.

It will impose a bit more structure on how you branch. Thats a good thing. You should be able to look at a branch and be able to figure out what goes in it, what doesn't go in it, where it is in the release cycle and work from there.

This helps in being able to identify exactly what role each branch has. You know where to go to build the latest release candidate. You know where to go to branch for a spike. You know how to get a hot fix into the product.

You could branch from the mainline for the sprint, branch from the sprint for each feature, merge to the sprint when the feature is done, and merge that back to the mainline. That works fine too. The sprint has the additional role of the accumulation in that case.

The key thing is to consider the different roles for each branch so that a developer knows what should and what should not go into any given branch. It will save you a lot of grief down the road by being able to reason about the structure of the branches.

  • wow. ok, thats going to take a bit of time to digest. Thanks for the input!
    – link64
    Oct 30 '15 at 1:04
  • @link64 welcome to branches.
    – user40980
    Oct 30 '15 at 1:05

Functionally mercurial will love as many heads to your repo as you can give it, even without using unique branch names -- you can use multiple anonymous heads for fun and profit at times.

Now, from a code and data management perspective you have to take a few things into consideration. Functionally you really don't want a lot of divergence between the sprints.

There is no reason not to just branch off of the sprint branch.

  • Would closing the sprint 1 branch have an adverse affect on the sprint 2 branch?
    – link64
    Oct 28 '15 at 23:12
  • Nope unless you need to merge into the sprint 2 branch. Even then you could branch off the last, non-closing commit to get there. Oct 29 '15 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.