“Hotfix” doesn’t have a single, specific definition, but Wikipedia describes one as “a single, cumulative package that includes information that is used to address a problem in a software product (i.e., a software bug).”

When it comes to version control systems, we usually see a slightly different usage of the word. I’ve usually seen it used to describe any sort of “quick fix” that’s applied directly to an existing software release, rather than going through a team’s normal software release process.

I’ve seen this take many forms, several of which I’ve been personally guilty of:

• Hacking on code on a live, production server
• Deploying code changes to production before it’s added to version control
• Creating a bug fix branch off of a “release” branch (as opposed to mainline or even develop)

One might assume that the goal in each case is to get the work done as quickly as possible, to restore production to a working state. But I’ve often seen these changes fail to get merged into mainline properly. Or the change that does get merged into mainline differs in some way from the version deployed. Sadly I’ve seen this happen too often even when attempting to follow GitFlow’s hotfix prescription.

All of these supposed short cuts are really bad ideas!

The whole reason that a software release process exists in the first place is to ensure that everything necessary for software to be safely and reliable released occurs. Any exception to this process means the process isn’t working.

If going through the normal channels takes too long to fix urgent bugs, fix the normal channels. Don’t shortcut them!