search

aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
493 stars 181 forks source link

merge behaviour after release-finish #213

Closed schnappfuesch closed 2 years ago

schnappfuesch commented 4 years ago

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

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 commented 4 years ago

I doubt gitflow script merges master to develop.

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

schnappfuesch commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@pennajenna I'll look into this.

pennajenna commented 3 years ago

@aleksandr-m --> I just submitted a PR for this: https://github.com/aleksandr-m/gitflow-maven-plugin/pull/291

aleksandr-m commented 2 years ago

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 commented 2 years ago

1.18.0 is released.

DManstrator commented 2 years ago

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 commented 2 years ago

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

DManstrator commented 2 years ago

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