Git Branching Model

The central repo holds two main branches with an infinite lifetime:

Main Branches

• master
• development

Supporting branches

Next to the main branches master and development, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases, and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited lifetime, since they will be removed eventually.

Feature branches

• Should branch off from development
• Must merge back into development

Release branches

• May branch off from development
• Must merge back into development and master
• Branch naming convention: release-*

Release branches support the preparation of a new production release. They allow for last-minute changes, they allow for minor bug fixes, and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the development branch is cleared to receive features for the next big release.

The key moment to branch off a new release branch from development is when development (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged into development at this point in time.

Creating a release branch

Release branches are created from the development branch. For example, say version v1.0.0 is the current production release and we have a big release coming up. The state of development is ready for the “next release”

Finishing a release branch

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into the master (since every commit on the master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into development, so that future releases also contain these bug fixes.

The release is now done and tagged for future reference.

Hotfix branches

• May branch off from the master
• Must merge back into development and master
• Branch naming convention: hotfix-*

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release but unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

The essence is that the work of team members (on the development branch) can continue, while another person is preparing a quick production fix.