We are using Gitflow for our git branch workflow (through TFS). When a release is successful we do the following
Step 1 creates a commit (Merged PR XXX: Merge release to master)
Step 2 creates a commit (Merged PR YYY: Merge release to develop)
When I look at our branches it says that develop is one commit behind master. This is because the commit (Merged PR: XXX) is not on develop.
Is the correct procedure to simply create another pull request from master to develop (even though there are no changes in pull request)?
I don't see this on the standard Gitflow model
This will be fiction length, so my apologies. The short answer I'm submitting is the completion of a git flow release should result in develop
being a commit ahead of master
based on how git flow origniator Vincent Driessen implemented his own git-flow scripts .
I'm not sure about your experience with git-flow
so forgive me if I'm stating the obvious. The git-flow
spec has a set of scripts to make its use easier. Git flow scripts ship out of the box with Git for Windows which I'm assuming you're using based on your TFS reference.
Let's check the history of a recent release via Git Bash
$ git log --oneline --graph --decorate
which yeilds
In the image above you'll notice
$ git flow release start v2.1.0
. release/v2.1.0
. This branch only contains one commit -- an increase in the version number. $ git flow release finish -k
release/v2.1.0
into branch master
master
into develop
to ensure all commits in the release branch make their way back into development of the next release. If you're using TFS PRs in your workflow you probably see something like this when you're ready to complete a release PR.
In my shop, we use PRs too, but I merge locally using $ git flow release finish -k
, then push the master
and develop
branches. TFS recognizes that the release branch has already been merged and will give you the option to "Close" rather than "Complete" the PR as shown below.
I've never done the extra merge you describe (or been on a team that did). I guess you could merge master to develop instead of merging the release to develop if you really wanted to - or, at least, I can't think of anything that would go wrong... But really, what's wrong with develop
being "behind"? It's basically the normal state of affairs in gitflow IMO.
In your scenario, the develop branch should have one commit behind master, and one commit ahead master (due to Merged PR YYY). If you create another pull request from master to develop, the develop branch will have another new commit (Merged PR ZZZ) and it will have one commit ahead master (Is it what you want?).
Instead of creating a Pull request from release to develop, you could just merge from master to develop.
TL;DR: you should back-merge the release tag (or master) into develop, instead of back-merging the release branch into develop, contrary to what the original article and most popular sources say, because of an issue with git describe
In the original article , and in the git extension from its author Vincent Driessen aka nvie, the command is:
git merge --no-ff $RELEASE_BRANCH
But this behaviour was causing an issue with git describe
, so a PR was open, implementing the following command instead:
git merge --no-ff $TAGNAME
(or, if their's no tag, git merge --no-ff master
)
Vincent Driessen approved this change, but apparently never got the time to make it official.
Then, since its extension was lacking active support, its fork gitflow-avh started, implementing the new behaviour, and became the new standard (the default on Windows and Ubuntu for example).
So, in summary, the behaviour of git flow release finish
should be something like:
git checkout master
git merge --no-ff $RELEASE_BRANCH
git tag -a $TAGNAME
git checkout develop
git merge --no-ff $TAGNAME
git branch -d $RELEASE_BRANCH
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.