How to cope with production rollbacks when using gitflow

Question

We're reviewing the popular Gitflow as our git branching model and I've liked it so far. One case I'm not sure about is the production rollback. Say we've there's a new feature that we're planning to publish in the upcoming release. The feature is tested and finally merged to master. Either automatically or manually the source code in the master is built and deployed. Shortly after deploying we reveal a critical bug and immediately create a hotfix branch. All right, so far so good. But we roll back the production version to the most recent working one. That means the program that's running in production does not match the source in the master branch. And anyone who branches off from master will something different that's really working. How do you cope with this case?

Answer 1

Shortly after deploying we reveal a critical bug and immediately create a hotfix branch. All right, so far so good. But we roll back the production version to the most recent working one.

There's some misunderstanding. If you apply a hotfix, it will increase the version. For example if the feature was merged and tagged version 1.4, then you apply a hotfix, you also increase the version.

That new version may be 1.4.1 or 1.4.0.1. At the same time you also merge the hotfix into your develop branch. Hence, master both changes are in master and in develop now.

Then you deploy your new version w/o the feature.

That means the program that's running in production does not match the source in the master branch. And anyone who branches off from master will something different that's really working. How do you coup with this case?

You don't roll back anything, you just deploy the fixed 1.4.1 (or 1.4.0.1 if you want to reserve the build version to planed maintenance) version with the feature removed.