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..?

[havvg]

I agree with @raveren. It's not part of the original model, to have a master (production branch) being ahead of the next upcoming release branch. If someone is following such a model, then git-flow is not the right tool for that job.

Actually, having the 2.0 within master (being the production branch!), how would you create a release being targeted to be merged into that branch, without being based on that very branch? This would require to commit into the production branch directly - for a fairly long time (derived by the major version increase) - which is against the branching model and probably not a good idea either.

Leaving the branching out of scheme, the timeline would be: develop -> feature -> develop -> release -> master -> develop (repeat), (fork:) hotfix -> master, develop, release.

In case you are supporting multiple versions (v1.1 released and v2.0 released having separate release branches), git-flow may ask the user whether to merge into any found release branch, if there are more than one. On a single version line setup, this question should be skipped.
Although my suggestion would be to use the support branches for that. In my experience the v1.1 would be deprecated and will be removed soonish. It solely exists for hotfixes. I normally use a separate clone with different git-flow configuration on those projects. This makes life easier as I'm using the same commands just with a different configuration.

[petervanderdoes]

Oh I totally agree this is might be an extreme, if not implausible, case but I have seen cases where people create release branches from support branches. I used this example to make it very clear about the problem that could arise if you have multiple release branches for multiple versions and you automatically want to apply a hot fix to all release branches.
Even with a release branch 2.1 and 2.2 you would "upgrade" the 2.1 release to 2.2.
Yesterday I started working on a new command, currently called cherry-pick but that probably will change, that would allow you to apply all commits from a hot fix branch to any other branch with just one command which makes it a little easier but not fully automatic. Let me know your thoughts on this please.

[havvg]

What's the use-case of having the release branches of 2.1 und 2.2 around? As far as I'm using git-flow, the 2.1 is deleted once closed on the very basic level. I think we should ease the 80-90% use-case, which is streamlined versioning based on the original git-flow.
There are so many different models you can create, there will be no limit. Putting it simple, an option to disable the merge into release branches should do the trick. Another option may disable this behavior only, if there are more than one release branch. Then you are able to use an adopted model, still required to manually synchronise upon different events (just like now when closing a hotfix) without messing around. But having this in place will help those using the basic git-flow.

What's the signature of the cherry-pick you mentioned?

[petervanderdoes]

The new cherry-pick command would be git flow hotfix cherry-pick <name> where name is the branch you want to apply all commits from the hotfix branch you are one, so maybe apply-to would be a better command. I would add some options from the original git cherry-pick command as well, like -s and -S

I'm not opposed to merging into a release branch, especially when we can decided to not doing the merge if there is more than one release branch. I would also add an option to the finish command, like -norelease-branch, in which case the hotfix won't be merged in the release branch.

[petervanderdoes]

Hmm, I just read a interesting story on why cherry-picking can be a problem.

If we would cherry pick the hotfix branch into release there could potentially be a problem when finishing the release branch. The problem is caused by the fact that the master and develop branch all ready have the commits from hotfix branch and those also exist in the release branch. See http://stackoverflow.com/questions/20380013/git-merge-strategies-spaces-make-default-shows-no-conflict-and-bring-unexpected

The only thing I can think of right now would be rebasing the release branch after the hotfix branch has been merged in develop.

[havvg]

That's not a limitation to the cherry-pick, but merges in general. That's why the --no-commit option exists. I don't suggest to start taking this into considerations. This should be done by testing the outcome (on a codebase e.g. by automated tests) rather than blindly believing everything is OK.
That's not something new, that would be introduced by merging the hotfix into the release, but it's already there when merging anything around and merge those results again and again. That's the whole point why a branching model exists; to have a more or less streamlined history by applying conventions over the technical possibilities of git itself in order to ease its use.

While I see use-cases for the cherry-pick, I don't see it being a valid substitute for merging the hotfix into release but rather an addition to other use-cases. The major advantage is not to have another command to run. That's what we are doing right now: "manually" merging the master into release, after hotfix finish.

[petervanderdoes]

Yeah, I just realized rebasing of of develop is just as bad. It would imply that develop remains untouched while there is a release branch, and that's not happening.

[macpharlan]

Hi folks, new to Git and Git Flow. I am going through the behavior and was surprised that the hotfix was only merged into master and develop when there was also a release branch present, I would think a hotfix on the latest release would need to go into current development as well as the next pending release.

Example:
master (latest release 7.0.0)
develop (current development 7.2.0)
release/7.1.0

If I create a hotfix for 7.0.0 (off of master) and finish it, I want that fix in current development (develop) AND my upcoming release (release 7.1.0). Default behavior should be to merge it forward to all new releases.

This model would also work with support branches, if I add the following to my above example:
support/6.0.1

Finishing a hotfix on 6.0.1 should at least give me the option to merge to master (7.0.0), release/7.1.0 and develop, covering all future work.

It seems to me that it would be a good feature to ask for intended targets when release branches are detected.

[HermannGruber]

Just fell into that hole. There is a new issue open on the original topic of this thread (#414 ), along with a proposed solution and a pull request. Looks promising to me.