We are using gitflow and currently have an open release branch.
The release at A is currently on the test-system to get tested by key-users. In the meantime we need to release an urgent hotfix. Commonly we pull out a branch of master (so the latest live-system release) and merge it into development and master. If we would do this here, we would not have the hotfix in the currently open release.
So what do I have to do at the point marked as “?” in the illustration? Assume that the hotfix is ready to get merged.
Yes, the gitflow workflow seems to miss this senario.
A Hotfix branch is merged back into master and develop when completed. But not the release branch!
When your release branch is completed it will be merged into master and potentially have a conflict or introduce a bug so this is not a good thing.
I would suggest that you merge master into the release after completing the hotfix. this will bring your feature branch upto date with master and allow you to test the hotfix in the new release.
However, an alternative would be to merge the hotfix into master, develop AND the release branch. you can see that this would be hard to automate as the release branch name would change each time.
(nb. many people prefer rebase to merge, but lets not get into that)
There is another possibility if you find this is happening a lot.
- Roll back the live release to the previous one.
- Add the fix to the next release
- Deploy the fix with the next release
Obviously this leaves you with an old version live, but if you are constantly doing hot fixes it points to a problem in your testing and release process.
Pushing for roll backs rather than hot fixes can be a good thing. Everyone is happier when releases go smoothly with no bugs and no rush to complete hot fix releases, but hot fixing essentially hides problems from the business. If you demand a roll back, this can focus the business on leaving more time for testing and feature completion. In the long run this can increase the speed of development.
Found it! Actually Atlassian is referring in their tutorial to a blog post of Vincent Driessen at nvie. And guess what? He’s the answer!
The one exception to the rule here is that, when a release branch
currently exists, the hotfix changes need to be merged into that
release branch, instead of develop. Back-merging the bugfix into the
release branch will eventually result in the bugfix being merged into
develop too, when the release branch is finished. (If work in develop
immediately requires this bugfix and cannot wait for the release
branch to be finished, you may safely merge the bugfix into develop
now already as well.)
From the chapter Creating The Hotfix Branch
In line with @ewan’s second suggestion above, wouldn’t the resolution of this issue come under nvie’s original mantra of “Master contains what is in production; Develop contains what *could be deployed” to production.”
So a hotfix reflects a update that must be deployed to production to keep Prod running.
Once the hotfix is completed, merged, and deployed it is merged back into Develop so that Develop once again contains what could be deployed to live.
And the hotfix is merged back in to Release.
Release branches should not be longed lived afaik.