Option to fast-forward master (when finishing release)

[jluttine]

I'd like to have a switch which made it possible to fast-forward master when finishing a release. Currently, a merge commit is always made. However, I don't see any reason why this would be necessary: next release is always based on the previous in git flow framework, so the master branch can always be fast forwarded.

A bit more details: Currently, release branch is merged to master and this merge commit is tagged. Then this tag is merged to develop. This could be simplified so that the tag is put at the end of the release branch, master branch fast forwarded to that point and then merged to develop. This could be made optional and enabled with, for instance, --ff-master switch.

Here's a simple init and release process as an example:

git init
git flow init
touch foo
git add foo
git commit -am "add foo"
git flow release start 0.1
touch version
git add version 
git commit -am "add version"
git flow release finish --ff-master 0.1

I'd like this to not create a merge commit to master branch.

Note that this is different issue than #235 which is about syncing master branch from origin before merging.

[jluttine]

I suppose this can be accomplished simply by putting --ff-only instead of --no-ff when merging the release branch to master: https://github.com/petervanderdoes/gitflow-avh/blob/develop/git-flow-release#L106.

[jluttine]

I could make a pull request for this but my solution would be in conflict with the current state of the master: ff-master is in use for something totally different.

[jluttine]

As ff-master is already reserved, perhaps ff-only? (Or any other ideas?) So, a release could be finished as:

git flow release finish --ff-only 0.1

Any thoughts on this matter? @petervanderdoes

[petervanderdoes]

Maybe I'm missing something, but how do you fast forward master to the release branch without merging it?

[jluttine]

Or maybe I'm missing something. I don't see any case where you couldn't fast forward master to the release branch. Could you explain such a case? Master has been merged to the release branch and that to the develop branch, then the next release branch starts from the develop branch at a later point. What prevents fast forwarding? In my opinion, master should only be fast forwarded always, merge commits don't add anything. So, master (and the corresponding tag) just points to the last commit of the release branch, which is then merged to develop. But I could be missing something. I need to experiment a little bit, I suppose.

[petervanderdoes]

When you start development the setup would be:

Master -> develop -> feature -> develop -> release -> master -> develop, but there is also master -> hotfix -> master. At that point the hotfix commits are not on the develop branch.

The other thing is I don't know of a git command that would do a fast forward only from branch to branch. Branches always need to be merged or cherry picked.

[jluttine]

I'm sorry but I don't quite follow. I guess I'm too unfamiliar with git and git-flow.. I'll try to answer anyway.

First: When finishing a hotfix, master can't be fast forwarded, the hotfix branch needs to be merged to master. Then, after finishing the hotfix, master is merged to develop, and then the following releases can be fast forwarded without problems. I don't see any issue here.

Second: git merge --ff-only branch does a fast forward from branch to branch, right?

Here's a very simple sketch of what I have in mind:

# Init stuff
mkdir git-flow-testing
cd git-flow-testing
git init
git flow init

# Some developing..
touch foo
git add foo
git commit -m "Add foo"

# Git Flow releasing
git flow release start 0.1
touch release-notes-0.1
git add release-notes-0.1
git commit -m "Add release notes 0.1"
git flow release finish 0.1

# Some developing..
touch bar
git add bar
git commit -m "Add bar"

# My (simplified) release process with fast forward
git flow release start 0.2
touch release-notes-0.2
git add release-notes-0.2
git commit -m "Add release notes 0.2"
git checkout master
git merge --ff-only release/0.2
git tag 0.2
git checkout develop
git merge master   # optionally with --no-ff

# See the difference between the two release processes
git log --graph

The latter release process is what I'm trying to suggest. The example is definitely missing lots of details and subtleties of git-flow but the main point is git merge --ff-only release/0.2. I don't see any reason why it shouldn't work. But I might be misunderstanding something.

[petervanderdoes]

Alright I get you now.

The reason for not always doing a fast forward merge is mostly because of history. If you look at a graph you can see when you merged a branch into another branch.

If you searched the internet for fast forward merge vs no fast forward merge you'll find a whole bunch of pros and cons for either one.

I'll see if could at a switch like --merge-ff to allow for fast forward merging.

[talios]

On Sat, Aug 20, 2016 at 5:47 AM, Peter van der Does < notifications@github.com> wrote:

Master -> develop -> feature -> develop -> release -> master -> develop, but there is also master -> hotfix -> master. At that point the hotfix commits are not on the develop branch.

Hotfixes should back-merge onto develop tho, at least they used to! So that should be fine when doing a new release branch.

'support' branches don't back merge to master OR develop tho.

"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

[raehalme]

Any update on this?

[hughescr]

Why does git-flow put any --ff-only or --no-ff options on the merge commands? Why can't users just express their preference for "always merge" or "don't merge" through ~/.gitconfig's [merge] section? Forcing either on or off, or requiring some flag to git flow subcommands when you've already expressed what you want in ~/.gitconfig seems a little perverse to me.

[hughescr]

eg. In my case I kind of want --no-ff to master from release, but I kind of want prefer-ff when going back to develop from master (assuming that noone injected anything in the meantime on develop), but my develop->release->master timeline is generally approximately instantaneous, so I can almost always FF develop to catch up to the release, and having the merge commit in the history is kind of un-necessary noise. I like to see the merge commits to master, because they commemorate what came in on each release, and the merge tree on master is nice and clean. develop gets so many merges from so many places (all the feature branches, bugfixes, from master,...) that reducing unnecessary merge commits there makes things easier to follow.

[Shea690901]

On Fri, Aug 19, 2016 at 5:47 AM, @petervanderdoes wrote:

When you start development the setup would be:

Master -> develop -> feature -> develop -> release -> master -> develop, but there is also master -> hotfix -> master. At that point the hotfix commits are not on the develop branch.

And with the next release we reintroduce the just fixed bug again.... Just because we forgot to merge the hotfix branch with both the release-branch (if it exists) and the develop-branch before finishing the hotfix...

[arnemertz]

I'm with @hughescr wrt. not forcing --ff-only or --no-ff. We explicitly set our repos to merge.ff = false and pull.ff = true, so we basically see nothing but merge commits on develop, and any actual changes go into the feature/bugfix/etc. branches. With the forced ff, finishing a feature may just forward develop to the last commit of that feature branch instead of explicitly adding a merge commit.

[philip-holmgren]

Alright I get you now.

The reason for not always doing a fast forward merge is mostly because of history. If you look at a graph you can see when you merged a branch into another branch.

If you searched the internet for fast forward merge vs no fast forward merge you'll find a whole bunch of pros and cons for either one.

I'll see if could at a switch like --merge-ff to allow for fast forward merging.

Bit late to the party but are there still plans to implement this? I'm assessing which workflow to choose for our team, I'm inclined to go for GitFlow but I consider the strict --no-ff as a drawback.

Ideally, I would like to have master and develop branch being identical ie sharing the same commit. Currently, GitFlow doesn't allow this because of the explicit merge commit AFAIK. Please correct me if I'm wrong, perhaps I'm missing something in the documentation, I'm fairly new at GitFlow.

[Forinil]

The only way I found to do this was

git flow release start 1.0.1
#set version and do other finishing tasks
git commit -m "Prepare for release 1.0.1"
git checkout develop
git rebase release/1.0.1
git checkout master
git rebase release/1.0.1
git checkout release/1.0.1
git flow release finish

It works the way I want it to, but in git flow only creates and deletes the release branch and creates a tag - the rest has to be done manually to avoid merge commit.