How to deal with a bugfix in GitFlow (or other process) once a release is ready to ship and merged into develop & master


April 2019


655 time


From :

Once the release is ready to ship, it will get merged it into master and develop, then the release branch will be deleted

Now that the merge is done : let's say we're now facing instability in production suddenly (how unlucky!), the master and develop branch are now temporarily out-of-sync with production environments and the release (let's say 1.1) is postponed. Later we find the issue that requires one or more fixes : What would be the best way in your opinion to deal with one or more bugfixes knowing that master and develop are now out-of-sync with prod ?

  • should I create a new release branch from develop (and name it for example 1.2), then revert changes from master and develop to latest production release tag (let's say 1.0)? If so : what would be the best way so the history of changes can be preserved as much as possible?
  • for those with real-life experience of release cycle : are you tempted to merge your release branches after a release or happy with doing so prior to a release?

EDIT : in summary this questions is really about clarifying the amount of work needed when dealing with bug fixes after a release cycle AND before the release has been deployed to environment. The objective is to clarify how many actions one may save by doing the release cycle merge (into master/develop) after the deployment to production environment (basically release to environment from a release branch rather than master).

1 answers


In the article you linked, it is stated that

The master branch stores the official release history[...]

Thus, the merge of the release branch into master is, by definition, a release. This is not the case in the workflow you described, as you have another production instance that gets updates from master in some distant future.

Having that said, I think the best approach in your situation would be to create a hotfix branch from production, fix your issues and merge it into production as well as into develop and master. The "release" from master can then proceed as planned, while your production issues are fixed as soon as possible.

That appoach is very close to the GitFlow hotfix workflow, as described in the article you linked. Since the only thing you're doing are bugfixes, a hotfix workflow is much more appropriate in contrast to a full-blown release.