Handling hotfixes when working only with git master branch

Question

I keep reading how people are forgoing the develop git branch and doing all work on master - and how this makes everything simpler.

I tried it:

• I have a master branch (with linear history) and many short-lived feature branches.
• I merge features into master.
• To release, I tag a commit on master - e.g. staging or 1.2.3 - to trigger my CI/CD tool to produce a staging or production release, respectively.

That works nicely... until one needs to release a hotfix.

Suppose I prepare a hotfix and merge it into main. There would be feature commits (feat) between the last stable release (1.2.3) and the hotfix (hotfix) - and if I deploy that last commit, it'll include all those miscellaneous features as well:

1.2.3 <-- feat <-- feat <-- feat <--hotfix

That's asking for trouble.

How does one deal with hotfixes in such a workflow?

Answer 1

Your options are:

1. Use a release (or hotfix) branch that you will discard later - see here for details - https://trunkbaseddevelopment.com/branch-for-release/ . Note here that if you make this your standard pattern and you use SemVer as in your question, the recommended way is to have each release branch on its own minor to avoid versioning collisions - see my post here for details - https://worklifenotes.com/2019/01/20/semver-in-production-always-keep-separate-production-branch-on-its-own-minor/

2. Roll forward with feature flags as suggested in the other comment - see my post here for details - https://worklifenotes.com/2022/11/02/on-feature-flags/

This may be a lot of information to go through, but these options if properly adopted should be enough to deal with any real-life situation.