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’.
This final post in the series focuses on our git branching strategy.
We follow a popular strategy commonly used by a number of other organisations. A great visualisation can be found here.
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.
We have four kinds of branches:
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.
Here are some of the naming conventions we use:
We are starting work on the next release 2.1. Here is a rough outline of the branching strategy we will most likely follow:
Done! Hopefully this post and the others in this series will have you helped improve your dev skills and productivity.
This article was originally written for Brightec by Seren Matthews
Search over 300 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!