From https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow :
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).