Hotfixes

The last thing we need to cover for our Git workflow is how to deal with bugs we discover in production (on our master branch). Although our code should have already been thoroughly tested before being added to master, subtle bugs are bound to slip through, and we must fix them quickly. This is call a hotfix.

Working on a hotfix branch is very similar to working on a release branch; the only difference is that we are branching off master instead of dev. Like with release branches, we'd make the changes, test it, deploy it onto a staging environment, and perform more testing, before merging it back into master, dev, and any current release branches:

So, first we make the fix:

$ git checkout -b hotfix/user-schema-incompat master
$ touch user-schema-patch.txt # Dummy hotfix
$ git add -A
$ git commit -m "Patch user schema incompatibility with social login"

Then, we merge it into master:

$ git checkout master
$ git merge --no-ff hotfix/user-schema-incompat

As we have added something new to master, it essentially becomes a new release and therefore we need to increase the version number and tag this new commit. Since this is a bug fix and adds no new features to the platform, we should increase the patch version to 0.1.1:

$ git tag -a 0.1.1 -m "Patch user schema incompatibility with social login"

Lastly, don't forget to merge the hotfix changes back into dev and, if relevant, other release branches:

$ git checkout dev
$ git merge --no-ff hotfix/user-schema-incompat

Our Git history tree now looks like this:

You can clearly distinguish the two permanent branches, master and dev, as everything seems to revolve around them. However, it's also clear that adding a hotfix makes the Git history more complicated than before, and so hotfixes should only be made when absolutely necessary.