Closed schnappfuesch closed 2 years ago
I doubt gitflow script merges master to develop.
Tags are mainly for releases. What tags do you want in the development branch?
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.
@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?
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.
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.
@pennajenna I'll look into this.
@aleksandr-m --> I just submitted a PR for this: https://github.com/aleksandr-m/gitflow-maven-plugin/pull/291
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.
1.18.0
is released.
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.
@DManstrator Read this issue and/or other duplicates for the reasoning. It is marked as breaking change because the default behavior has changed.
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. :)
I'm wondering if there is a way to change the behavior when finishing a release, so that we do not
release/1.3.0
tomaster
and thenrelease/1.3.0
todevelop
but insteadrelease/1.3.0
tomaster
and thenmaster
todevelop
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!