merge behaviour after release-finish

[schnappfuesch]

I'm wondering if there is a way to change the behavior when finishing a release, so that we do not

• merge release/1.3.0 to master and then
• merge release/1.3.0 to develop
  but instead
• merge release/1.3.0 to master and then
• merge master to develop

as it is done by e.g. gitflow script itself.
I mainly missing the tags on the develop branch. (Yes i could simply merge master into develop myself).

mvn gitflow:release-finish
...
[INFO] Checking out 'release/1.3.0' branch.
[INFO] Cleaning and testing the project.
[INFO] Checking out 'master' branch.
[INFO] Merging (--no-ff) 'release/1.3.0' branch.
[INFO] Creating '1.3.0' tag.
[INFO] Checking out 'develop' branch.
[INFO] Merging (--no-ff) 'release/1.3.0' branch.
...

Cheers and thanks for the tool!

[aleksandr-m]

I doubt gitflow script merges master to develop.

Tags are mainly for releases. What tags do you want in the development branch?

[schnappfuesch]

Your are kind of right - git flow does not directly merges master back into develop but 'only' merges the just created tag back into develop.

mkdir foo && cd foo && git flow init -d
touch foo1 && git add foo1 && git commit -m "foo1 added"

git flow release start 1.0.0
touch foo2 && git add foo2 && git commit -m "foo2 added"

git checkout develop
touch foo3 && git add foo3 && git commit -m "foo3 added"

git flow release finish '1.0.0'
....
Summary of actions:
- Release branch 'release/1.0.0' has been merged into 'master'
- The release was tagged '1.0.0'
- Release tag '1.0.0' has been back-merged into 'develop'
- Release branch 'release/1.0.0' has been locally deleted
- You are now on branch 'develop'

I like to see the release tags, when working on develop, as it gives me a clearer idea of what has happened in the past.

Remark: The above excerpt is from the git-flow tool of the current LTS version of Ubuntu. I thought it had the same origin as the above link, but I'm not so sure anymore.

[aleksandr-m]

@schnappfuesch
Seems like avh version indeed merges tag/master to develop. Can you tell a bit more what benefits does it bring to you to merge it that way? What are you using to see branch history?

[schnappfuesch]

Hi @aleksandr-m,

sorry for the late response, I was away.

The main reason why I would like to have this feature is to get a better overview of what happened since the last release.

We have a lot of smaller components that will be released a few times a year and I'm regularly asked questions by colleagues responsible for those components.
Of course I could look out for merge commits, but a tag would make it easier for me to get a clearer understanding of what really happened.

[pennajenna]

Is there a workaround for this or will this be considered for a fix? Its a need for our software lifecycle, so I'll need to figure it out or a possible workaround.

[aleksandr-m]

@pennajenna I'll look into this.

[pennajenna]

@aleksandr-m --> I just submitted a PR for this: #291

[aleksandr-m]

Similar like avh gitlfow handles this now tag or production branch will be merged to develop. To restore previous behavior and merge release branch use noBackMerge parameter.

[aleksandr-m]

1.18.0 is released.

[DManstrator]

Sorry if this is the wrong place to ask but what is the advantage of merging the master into the develop over merging the release branch into the develop? I googled for it but couldn't find an answer there.

And are there any downsides to this approach? This is a breaking change according to the release notes so I assume there are some downsides.

[aleksandr-m]

@DManstrator Read this issue and/or other duplicates for the reasoning. It is marked as breaking change because the default behavior has changed.

[DManstrator]

Thanks for the hint to read the linked issues. I have actually read this issue but didn't get quite the reason, but got it with #321.

I actually think that GitLab doesn't treat tags correctly since they seem not to be branch-related but repository-related there. This was also confusing me since it looked like the tags were already correct before this change was applied. Nevertheless, this is now really unrelated to this issue, I will keep it since it fixes an issue and is approved.

Thank you. :)