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.
-
1Is this a duplicate of How should I incorporate a hotfix back into a feature branch using gitflow??Martin Nyolt– Martin Nyolt08/25/2016 08:02:07Commented Aug 25, 2016 at 8:02
-
that's actually a subtly different question about feature branchesEwan– Ewan08/25/2016 08:08:10Commented Aug 25, 2016 at 8:08
3 Answers 3
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)
**edit **
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.
-
What happens if I merge Release into development again? Wouldn't that be a conflict since the system doesn't know whether the "release-hotfix" or the "development-hotfix" is the real code?OddDev– OddDev08/25/2016 08:21:36Commented Aug 25, 2016 at 8:21
-
when you complete the hotfix it is merged to dev. when you complete the release it is also merged to dev. if you get a conflict (with new features and changes in release) at this point you will have to resolve it manually, But you wont get a conflict merging to master which is the important thingEwan– Ewan08/25/2016 08:33:49Commented Aug 25, 2016 at 8:33
-
Also, i guess the standard advice is 'dont do hotfixes'. so hopefully this is a rare occurrence!!Ewan– Ewan08/25/2016 08:37:32Commented Aug 25, 2016 at 8:37
-
@Ewan i like your second scenario in the case of the release branch being a bit more longer lived than expected. And of course depending on the extent and nature of the hotfix needed!Rob Wells– Rob Wells01/25/2019 15:46:57Commented Jan 25, 2019 at 15:46
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.