Hello and happy Friday!
Today we’ll be wrapping up our tour of semantic versioning and the Git branching model’s supporting branches. The last supporting branch from our workflow is the hotfix branch.
First off, lets list the mechanics of this supporting branch:
- May branch off from:
- Must merge back into:
- Branch naming convention:
Hotfix branches are similar to release branches in that they are also meant to prepare for new production releases. The difference between the two is that a release branch is planned whereas a hotfix branch isn’t.
Hotfix branches arise from the need to quickly address some undesired state of the production version of our code. When a precarious bug in our production source must be handled immediately, we should branch off from the corresponding tag on
The goal is to allow other team members to continue to working on
origin/develop while another team member can make the necessary fixes.
Creating a Hotfix Branch
Since a hotfix branch is always created from
origin/master we don’t have to worry about any instability from needing to branch off from
origin/develop which may not currently be in a stable state.
Here’s an example:
git checkout -b hotfix 2.6.0 master ./bump-version.sh 2.6.0 git commit -a -m "Bumped version number to 2.6.0"
Next, we fix the bug(s) and commit the fix.
git commit -m "Fixed that crazy bug of it's craziness"
Finishing the Hotfix Branch
Now we need to merge the finished code improvements back into
origin/develop to ensure that this bug fix will also be included in the next release.
This is redundant of how we finished off our release branches from yesterday:
origin/master and tag the source release.
git checkout master git merge --no-ff hotfix-2.6.0 git tag -a 2.6.0
Next, we need to also include this bugfix in
git checkout develop git merge --no-ff hotfix 2.6.0
And that’s it… Except for this caveat.
A Caveat Conclusion
There is one exception here. When a release branch currently exists, the hotfix changes need to be merged into that release branch instead of
origin/develop. The reasoning is that by merging the bugfix into the release branch it will eventually be merged into
origin/develop as well, when our release branch is finished.
If our source in
origin/develop immediately requires this bugfix to be present however, we can feel free to safely merge the bugfix into
origin/develop right away.
Our one remaining step is just removing our temporary hotfix branch:
git branch -d hotfix-2.6.0
And that wraps up my overview of this Git workflow.
Have an enjoyable weekend 🙂