hotfix finish should back merge into release branch

[jeroenhouben]

Hi,

I think it would be nice if "git flow hotfix finish" would merge back into the release branch, if there is one. I think it makes sense for the release branch to automatically obtain the latest hotfixes. Or am I overlooking something? Is this something you can currently do with git flow?

[jeroenhouben]

Taken from http://nvie.com/posts/a-successful-git-branching-model/ under "Finishing a hotfix branch"

"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.)"

[AckermanMD]

So, I guess most people are happy to either:

a) manually merge hotfixes into the release branch, if there is one, or,

b) rest assured that when they merge the release into master and develop, they wont accidentally resolve conflicts with theirs instead of ours?

Thoughts? Beuller?

[pcg79]

I came here hoping to find this issue open. I'm sad to see it's gone stale. I'm even sadder to see that if someone were managing this repo it would be closed as a duplicate of #3 (just as #61) was.

Anyway, this is my only problem with using git flow. I'm constantly forgetting to merge hotfixes back into our existing release branch.

[petervanderdoes]

My question about this request is: how to determine on which release branch the hotfix should apply?

You can't just assume the latest, well I guess you could but that could lead to all sorts of problems. What if there is no unreleased released branch and you keep the released release branches?

[pcg79]

Might as well do all of them. If the user doesn't want to, they can stop the merge manually. I'm more curious to know how many release branches ppl create at once and why. We never have more than one.

[petervanderdoes]

I agree with you that I don't see the point of creating multiple release branches, but git flow release has the option to keep release branches. So it's not a release branch in progress, it's a finished release kept for what ever reason. So you can't just apply a hotfix to all of them.

I guess you could solve this with a hook script, post-flow-hotfix-finish. This script would be called at the end of the git flow hotfix finish command. These hook calls have been implemented in my fork https://github.com/petervanderdoes/gitflow

In that script you could do a git merge in your release branch. Quick and dirty:

#!/bin/sh
#
# Runs at the end of git flow hotfix finish
#
# Positional arguments:
# $1    The version (including the version prefix)
# $2    The origin remote
# $3    The full branch name (including the feature prefix)
#
VERSION=$1
ORIGIN=$2
BRANCH=$3

# Implement your script here.

RELEASE_PREFIX=$(git config --get gitflow.prefix.release)

# Get the release branch with the latest commit date.
RELEASE_BRANCH=$(git for-each-ref --sort=-committerdate refs/heads/$RELEASE_PREFIX --format='%(refname:short)' --count=1)

git checkout $RELEASE_BRANCH
git merge --no-ff "$BRANCH" || die "There were merge conflicts."

exit 0

This isn't perfect, for one if the merge fails the hotfix branch will be deleted. You could compensate with keeping the hotfix branch.

Is this a better option as adding another flag to the hotfix command?

[dcopestake]

I am having issues with this as well as I've ended up releasing with hotfixes missing because they aren't being merged into the ongoing release.

The point about "which release branch to merge into"; doesn't git flow say that there should only be one ongoing release branch at a time? For example; if I try and start a new release whilst I already have one ongoing, git flow will error saying that I need to finish the current release (i.e. merge and delete the branch). So couldn't the behaviour be that - when finishing a hotfix - if:

• A single release branch currently exists; then that is merged in to and not straight to develop
• Multiple release branches exist; then fail with a message indicating that it's unknown where to merge the hotfix since multiple releases are ongoing
• No release branches exist; merge into develop as normal

Maybe the flag to override all of that is to just skip the automatic merge all together and allow the user to do that, which would allow for these different scenarios.

I know some people may want to keep release branches around, but that would break other points in the flow using standard options, so why not this as well?

[andreaskern]

+1

[masimplo]

+1

[juanitogan]

I completely agree with @dcopestake. It is the obvious solution and git-flow should have been built this way from the start if it was intended to match Driessen's post from 05 Jan 2010.

I was so bothered by this missing detail from git-flow that I created an updated git-flow-ish diagram to remind us where hotfixes need to go during release development. It is published here: https://www.lucidchart.com/community/software/git-flow-flipped-/8993117e-878b-4817-b9cd-ad07ea2f38d9

BTW, this is NOT a duplicate of #3. It is, however, a duplicate of #61 (which was incorrectly closed as a dupe of #3).

[michalmikolajczyk]

+1 just ran into this issue, agree with @dcopestake and @juanitogan hotfix branch should merge into release branch, if available.

[tothsanka]

+1

[digitalgears]

+1

[benpriestman]

+1

[borice]

+1

[andreacremaschi]

+1

[leocalzavara]

+1

[dools]

+1

[raveren]

Is this critical issue seriously open after four years?

[raveren]

oh, the project is abandoned, use https://github.com/petervanderdoes/gitflow instead of this one.

[tothsanka]

LOL :+1: for @raveren

[srt32]

@tothsanka @raveren mind making some noise on https://github.com/nvie/gitflow/pull/419, which I opened in an attempt to get the README updated to include the unmaintained status of this project.

[Grendel61]

Actually I just tested this process, and it works the way you would hope. I think the key is how you start the hotfix. I started with:

git flow hotfix start [hotfix name] release/[release name]

I used the whole branch name (e.g. release/[release name] which may not be required).

This set up the references appropriately from the start. Then I did a: git flow hotfix finish (hotfix name)

This only merged the changes into the release branch. On Github we set our default branch to the Release so that we don't inadvertently merge into master or develop. I checked master and develop both locally and on my remote and neither were populated by the "finish".

Carefully squeezing the release name into the "hotfix start" is extra work, but it takes care of a number of git commands.

Hope this helps.

[mystcreater]

+1 :)

[stralytic]

+100

[emannuel]

+1

[Regenhardt]

Amazing, an open issue almost as old as the original blog post itself. The flow is a de-facto standard by now, would be nice to have a single de-facto-official repository with old ones referencing it.

[ChrisJStone]

Amazing, an open issue almost as old as the original blog post itself. The flow is a de-facto standard by now, would be nice to have a single de-facto-official repository with old ones referencing it.

See gitflow-cjs for maintained fork