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.