Branching Strategy

Default blog image of logo on green
This is the final post in the series - ‘Evolving the Dev Process’.

Evolving the Dev Process

Over the last few weeks we’ve been exploring some of the processes and procedures we’ve put into place here at Brightec to aid our development and project management. This is the final post in this series - ‘Evolving the Dev Process’.

Find the previous posts in the series here: Part 1 - Why Continuous Integration?, Part 2 - Code Style expectations and Part 3 - Code Standards.

This final post in the series focuses on our git branching strategy.

A good branching strategy

We follow a popular branching strategy commonly used by a number of other organisations.

A good branching strategy should be simple and easy to understand. You should be easily able to identify which branch contains which features. Also, it should be flexible enough to cope with agile workflows and quick releases.

As a developer I should be able to work on the next release, whilst other team members are prepping the current release in another ‘safe’ tested branch.

Our branches

We have four kinds of branches:

  • Master (what’s in the app store)
  • Release (the next major release)
  • Dev (Work in Progress for next major release)
  • Feature branches (correspond to Jira Tickets)

The Dev and Master branches last forever, the others are transient. New stories are worked on in the feature branches off of Dev.

Dev will always contain all the new features we are working on for the next release. If we are already about to release, we would use a release branch. For example - 2.1-release and a dev branch Dev which contains tickets for the 2.2 release.

The release branch allows us to cherry pick what will be included, bug fix, test and stabilize. Fixes in release can be pulled into dev. When a release is production ready, it will be merged into master and tagged.

Naming conventions

Here are some of the naming conventions we use:

  • Master - Master Branch
  • Dev - Dev Branch
  • X.X-release - Release Branch
  • LCA_000 - Feature Branch (named after Jira ticket)

An example

We are starting work on the next release 2.1. Here is a rough outline of the branching strategy we will most likely follow:

  • As a developer I will take my Jira tickets and create a branch from the Dev branch, this branch could be called LCA_562
  • I finished work on the branch, squash commits, and pull request to dev branch
  • Code review is successful, so I merge into the dev branch
  • Deadline for 2.1 is looming, we’ve finished development, we create branch release_2.1 from Dev and set version numbers, release params etc
  • We send 2.1 off for testing
  • A few bug fixes are required, create another feature branch LCA_333 for example, fix the bug, pull request and merge back in
  • We then code freeze 2.1, merge into master and release
  • Master is tagged with release_2.1 and we may end up branching for any last minute hotfixes

Done! Hopefully this post and the others in this series will have you helped improve your dev skills and productivity.

Evolving the dev process

Don't miss the previous posts in the series here: Part 1 - Why Continuous Integration?, Part 2 - Code Style expectations and Part 3 - Code Standards.

This article was originally written for Brightec by Seren Matthews


Looking for something else?

Search over 400 blog posts from our team

Want to hear more?

Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!