In my last post, we took a brief tour of a feature branch, the first of three supporting branches in our Git branching model.
Today we’ll be continuing our tour and have a look at the next supporting branch which is a release branch.
Here are the mechanics of this particular branch:
A Release branch…
- May branch off from:
- Must merge back into:
- Branch naming convention:
The purpose of a release branch is to allow for minor bug fixes and last minute tidying up of the code before production. With us being able to perform this work inside of a release branch, we free up the
develop branch to receive features for the next big release.
When to create a Release Branch
origin/develop nearly reflects the desired state of the new release, then we can branch off our new release branch from
origin/develop. Any features targeted for the ‘next upcoming release’ must be merged into
origin/develop at this time. And any features with future release aspirations need to wait until after the release branch is branched off before adding them.
Creating a Release Branch
Depending on the current version of our software and the type of release we’re wanting to commit (remember MAJOR.MINOR.PATCH from this post?), we branch off from
origin/develop and give our new release branch a name that reflects the new version number.
Here’s a short example:
git checkout -b release-2.6.0 develop ./bump-version.sh 2.6.0 git commit -a -m "Bumped version number to 2.6.0"
Note that after creating and switching to our new branch, we bumped up the version number. In the code illustration above on
bump-version.sh is a fabricated shell script that changes some files in the working copy to reflect the new version. This could have also just been a manual change, but doing either the fabricated or manual changes (the point being that some files have changed) the bumped version number is then committed.
This new branch will exist until the release is with certainty ready to push. During this time, bug fixes should be made in this branch instead of
origin/develop. Any large features should never be made on this branch, but instead merged into
origin/develop and wait for the next big release.
Finishing a Release Branch
When the code of our release branch is ready to actually become a release, we have a few things to take care of. First we want to merge our release branch into
origin/master (since every commit on
origin/master is a new release by definition). Next we need to tag our
origin/master commit for future reference to this historical version. And then the changes made on our release branch need to be merged back into
origin/develop, so that future releases will also include these bug fixes.
Here’s another quick example:
git checkout master git merge --no-ff release-2.6.0 git tag -a 2.6.0
This release is now tagged for future reference and we’re nearly done!
In order to keep the changes made in our release branch, we should merge these back into
git checkout develop git merge --no-ff release-2.6.0
The last step from the paragraph above could potentially lead to a merge conflict. But we can fix and recommit.
Here are a few links to get us started in this direction if need be:
- Fix merge conflicts in Git
- Resolving merge conflicts from the command line
- rt Camp’s resolving Git merge conflicts tutorial
- A tutorial from the GitGuys
- Painless merge conflict resolution in Git
And once these steps are complete we can remove the release branch like so:
git branch -d release-2.6.0
In my next post, I’ll be covering the final supporting branch.
Look out for my review of Hotfix branches.