Inside kwiboo – 7 golden rules of “Branch per Task”

At kwiboo we’re agile, and we use agile methodologies to deliver our projects. The “Branch per Task” approach is used to develop pieces of functionality during a development cycle.

As a bespoke software development house, quality is key. We have been using “Branch per Task” for years and have learned some key lessons along the way.

The following list should get you up to speed very quickly with “Branch per Task” and if you stick to these 7 golden rules of “Branch per Task” you’ll be branching and merging like a pro in no time.

1 – Keep your branches small

Long running branched can cause a headache when it comes to merge, especially if there is a large team working on a project. You may have come across the Salesforce Benefits of using a proper customer relationship management software to manage your customers, but that simply wouldn’t suffice for management. Long running tasks should be sprints, with the work split into tasks.

2 – Stick to the scope of your task

If you’re working on a task, and you happen to notice a bug on an unrelated component, leave it alone and raise it as a task. The chances are another developer is already due to fix it or already has. Not only will you cause a merge conflict, you’ll be doing the work twice. Stay focused on the task at hand, try not to cross the streams.  Merge conflicts are an indication that the scope of your work has crossed with someone else, at this point you should talk as a team.

Accountability (blame) and code reviews are much easier if the task branch only contains changes related to the task.

3 – Check-in regularly

When working on a task branch, check in regularly. Sometimes it’s necessary to compare how your code works now with how it worked before. This is especially important when re-factoring or if some code has just stopped working completely. Being able to trace your steps is a real advantage.

4 – Check-in before merging

If you are about to re-base, “cherry pick” or simply merge another branch into the branch you are working on, make sure any pending changes are checked in first. You’ll need somewhere to go back to if it all goes wrong.

5 – Label, Label, Label

Automated releases using Continuous Integration (CI) tools like Jenkins, should automatically label the change set in source control. Make sure the label reflects the environment it is being released to; Live, Pre-Live, Dev, UAT etc.

6 – Don’t forget about Shelves

From time to time, you may get yourself in a pickle or you may be working on the wrong branch (naughty). Shelve your changes so you can re-apply them to the correct branch.  Shelving is a key tool, get familiar with it as its a great help.

7 – Don’t have a “multi-purpose” release branch

Making your CI always release from a /Main/Release branch and merging whatever you are releasing into this branch is a no no. You’ll cross-contaminate your source, leaking features from one branch through to another.

Instead, release from the branch you are testing. Keep the trunk branch clean, it should only contain live released change sets (labelled of course).


All of the 7 golden rules of “Branch per Task” have been learnt by kwiboo on Plastic SCM, DVCS. A source control platform is a key tool in a development team, and with the right source control you can unlock the power of your team, concurrent working on feature sets as well as system maintenance in live.

For us the Plastic SCM interface is world class and there is something to be said for being able to see what is going on in a project. Plastic also has a command line (which is great for scripting), but lets face it, with an interface as good as Plastic’s why use anything else.