merge hotfix into current release

[havvg]

If there is a release branch present (locally) and I finish a hotfix the resulting master branch should be merged into the release branch, too.

Currently the hotfix is only merged into master and develop.

This may be optional. We got a release management including RC versions, which are based on the current release branch. However, currently we need to manually merge the master back into release branch when finishing a hotfix.

[timwhite]

This is something we'd like too.

[andreaskern]

this is actually expected behavior

... when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop
http://nvie.com/posts/a-successful-git-branching-model/

[andreasciamanna]

What's the development status of this feature?

How do you suggest to workaround this meanwhile?
Manually merging master with the release branch every time there is a new hotfix?
Or just go the old style and manually create branches from the release branch, and merge them mach to that release branch once completed?

[raveren]

This is unbelievable. More than four years without a fix.

nvie/gitflow#177

It's a ticking time bomb, rendering the whole tool useless.

[petervanderdoes]

Alright opening up an old issue here. :)

1. The PR given is to merge the hotfix in all open release branches.
   Problem with this is that you will merge more commits, not just the hotfix branch.
   Explanation: I have a release branch for v1.1 and the master is v2.0. I do a hotfix on the master, if I merge the hotfix in the release/v1.1 the release branch will be updated to v2.0 + hotfix.
   I did a test with the git-flow repo:

git co master
git co -b release/1.8.0 1.8.0 
git co master
git co -b hotfix/1
touch f
git add .
git commit -a

Result:

[hotfix/1 7ea2a04] -New file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 f

Next

git co release/1.8.0
git merge hotfix/1

Result

Updating 5d9a2d2..7ea2a04
Fast-forward
 AUTHORS                        |   8 +-
 Changes.mdown                  |  31 ++
 LICENSE                        |   2 +-
 Makefile                       |   3 +-
 README.mdown                   |  42 ++-
 contrib/gitflow-installer.sh   |   4 +-
 f                              |   0
 git-flow                       |  36 +-
 git-flow-bugfix                | 818 +++++++++++++++++++++++++++++++++++++++++
 git-flow-config                |   9 +-
 git-flow-feature               |  44 ++-
 git-flow-hotfix                |  39 +-
 git-flow-init                  |  37 +-
 git-flow-log                   |  52 +--
 git-flow-release               |  30 +-
 git-flow-support               |   5 +-
 git-flow-version               |   4 +-
 gitflow-common                 |  38 +-
 hooks/post-flow-bugfix-delete  |  21 ++
 hooks/post-flow-bugfix-finish  |  21 ++
 hooks/post-flow-bugfix-publish |  21 ++
 hooks/post-flow-bugfix-pull    |  21 ++
 hooks/post-flow-bugfix-start   |  23 ++
 hooks/post-flow-bugfix-track   |  21 ++
 24 files changed, 1199 insertions(+), 131 deletions(-)
 create mode 100644 f
 create mode 100644 git-flow-bugfix
 create mode 100755 hooks/post-flow-bugfix-delete
 create mode 100755 hooks/post-flow-bugfix-finish
 create mode 100755 hooks/post-flow-bugfix-publish
 create mode 100755 hooks/post-flow-bugfix-pull
 create mode 100755 hooks/post-flow-bugfix-start
 create mode 100755 hooks/post-flow-bugfix-track

[raveren]

I have a release branch for v1.1 and the master is v2.0

Isn't this not only an edge-case but slightly against the gitflow model itself? If your master is ahead of release or you are supporting multiple version production branches, gitflow won't cover that - it's a well-defined flow, and custom domain logic should not be catered to..?