Simplified Feature Branching - Source Control Done Right

Introduction

As one does typically develop features in parallel, and some features cannot be released while others can, a lot of software teams seem to have problems with their source control.

In this post, I will describe Simplified Feature Branching usable with GIT or any other DVCS.

This model is not rocket science, and is a further simplification of Adam Dymitruk's post on feature branching.

It assumes you use proper release cycles and versioning during the software development lifecycle.

Whenever I mention "feature" in this post, I actually mean "feature" or "bugfix", but I am a lazy b*d.

The Main Idea: Simplification

Make everything as simple as possible, but not simpler - Albert Einstein

Whenever things start to get complicated, we should attempt to simplify them by breaking it up into smaller parts. This is exactly what Simplified Feature Branching does. We make the distinction between branching and integration.

Feature (and Bugfix) Branches

In large development teams, we typically have the problem that several things are developed in parallel, and need to be integrated afterwards. What we will do is separate these two concepts.

We will forget about integration for now, and will just create a branch for every new feature or bug-fix we perform. We will give the branch a proper name (usually, that will be some kind of an ID we get from a tracking tool).

The Development repository would look like this:

• Development
  • master
    • [Bug fix] *
    • [Feature] *

For example:

• Development
  • master
    • Bug-sales-123123
    • Bug-marketing-5454
    • Feature-sales-444
    • ...

All branches would be children of Development/master. Exceptions are not allowed, unless you really, really need it and know what you are doing.

This is exactly the same as Adam's model.

Integration Branches

Integration branches are the branches where we integrate the different features in a new branch. A typical workflow during development would look like this:

git checkout master
git branch dev
git checkout dev
git merge Bugfix-1231
git merge Feature-5454
...

Once we are satisfied with this integration, we typically deploy this dev branch to the shared development environment.

Never Alter Development/Master!!

Important to note here, is that the whole process described here is targeting the development process, not release management, and this is exactly where the simplification starts.

Integration branches are just temporary placeholders. Think about it! Integration branches should be dropped and recreated once a release is finalized!!!

I would even suggest you to make this explicit by having a distinct repository for the release integration. As one typically goes through a process where multiple clients might have requested different features, I would opt for the following approach:

• Repo: development
  • master
    • [Bug fix] *
    • [Feature] *
• Repo: releases
  • master
    • staging
    • QA/[customer] *

Here is the simplification: integration branches are just temporary things, which can be dropped and recreated as you want. Let's say you want to setup a QA environment for a certain customer in the releases repo:

git checkout --track development/Bugfix-1231
git checkout --track development/Feature-5454
git branch -D QA/JohnTitor  // drop the branch if it exists
git checkout master
git branch QA/JohnTitor
git checkout QA/JohnTitor
git merge Bugfix-1231
git merge Feature-5454
git branch -D staging  // drop the branch if it exists
git checkout master
git branch staging
git checkout staging
git merge Bugfix-666
git merge Feature-42

This will allow you to have proper branches per customer QA environments and a staging environment (for the final release).

Once the version on the staging environment has been approved by all the customers, we do the following:

git checkout master
git merge staging
git tag v1.2.3

As all changes are now integrated in the master, we can drop all the feature branches.

git branch -D Bugfix-1231
git branch -D Feature-5454
git branch -D ...

So all your releases are on the main branch. Once a release is done, you open up GIT on the development repository, and type the following:

git checkout master
git pull --rebase releases
git branch dev

And voila, your development repository is up to date!!!

And an Added Bonus

One does not have to have a single development repository, for example one could have one per development team/country/division/... (In my current project, we will use a separate repository for outsourced work for example). This approach would also integrate very nicely with code reviews and other CI-related things.

By creating this simplified feature branching model, one clearly separates responsibilities using multiple repositories, and makes sure the whole integration process is centralized and separated from development.

Happy simplified feature branching everyone!!

PS: Do not forget to enable GIT rerere when merging git branches; this might save you a lot of time... In fact, Adam even suggests sharing your merge cache folder...