发布后 Gitflow 在 master 后面开发分支

Question

We are using Gitflow for our git branch workflow (through TFS). When a release is successful we do the following

1. Pull request from release to master
2. Pull request from release to develop

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

Answer 1

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 .

What ... 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.

Result of a Recent "v2.1.0" release

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

1. A file upload feature was merged into develop. At this point, I wanted to release the product.
2. To release, I issued $ git flow release start v2.1.0 .
3. The "git flow release start ..." command automatically created branch release/v2.1.0 . This branch only contains one commit -- an increase in the version number.
4. At this point I've tested and am happy with the release so I finish it using $ git flow release finish -k
5. The "git flow release finish" command will in order
   • Merge branch release/v2.1.0 into branch master
   • Create an annotated tag for release v2.1.0
   • Merge branch master into develop to ensure all commits in the release branch make their way back into development of the next release.

But what if I'm using TFS PR's?

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.

Answer 2

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.

Answer 3

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.

Answer 4

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