Project Ramon

A learning journey from a Ruby noob perspective

Git Branching Model[Support Branches]: A Look at the Hotfix Branch

hotfix_branch_header_img

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.

Hotfix Branches

First off, lets list the mechanics of this supporting branch:

Hotfix branches..

  • May branch off from: origin/master
  • Must merge back into: origin/develop and origin/master
  • Branch naming convention: hotfix-*

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 origin/master.

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/master and 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:

First, update 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 origin/develop:

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 🙂

Advertisements

Categories: Versioning

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s