Gitflow develop branch behind master after a release

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

Narvik

Answer 1

This will be fiction-length, so my apologies. The short answer I'm submitting is the completion of a Gitflow release should result in develop being a commit ahead of master based on how Gitflow originator 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 yields

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.

Antarctica

This makes sense. Thanks for explaining. – Narvik

Checking out the git flow scripts linked, it seems that Merge branch master into develop to ensure all commits in the release branch is wrong. It merges from the release branch to master & develop. So the OP is right, the master branch should be more ahead with each release if you use the git flow scripts (dev too but this is fixed on the next release as the release commit returns to master). But I might have read the scripts wrong. I found this question because we have a debate on our team about doing a --no-ff and regularly merging master to develop or doing --ff-only – Whimsey

@JulienN: I haven't read the Git Flow scripts, so you may be right. I can tell you that we use Git Flow for several projects in our shop and git flow release finish always results in the graph I've posted in the first picture. Notice merge commit 953492f (develop's tip) has commit a14b2aa (master's tip) as one of it's parents. – Antarctica

It seems you do not use Vincent Driessen's gitflow but its fork, gitflow-avh (see the answer to "Why does git-describe not work for me?" describing the current implementation, and the crossed out previous answer describing the original behaviour) – Honourable

See my answer for more information – Honourable

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.

Metagnathous

Why would develop be behind master? The only time I can think of when this would happen is if a hot fix branch was taken from master. – Narvik

@Narvik : ????? For the exact reason you described in the question... – Metagnathous

I understand why it's got behind. However if I have lots of empty "merge" commits that aren't on develop it makes it harder for me to spot a real change - such as the hotfix that I need to merge into develop. If a dev doesn't spot this they could create a release with the hotfix removed and deploy that to a prodction environment. – Narvik

@Narvik - If we're discussing gitflow, then at the same time you merge the hotfix to production you merge it to the open release (or develop if there is no open release). Gitflow uses branch and merge patterns in a way that a developer cannot make the mistake you describe other than by varying from gitflow (and doesn't need to rely on brittle analysis of "branch behind" counts to avoid it). Of course gitflow isn't the only way, but it is what you asked about. So my question stands: in gitflow, why do you think it's a problem for develop to be behind? – Metagnathous

@MarkAdelsberger I agree it's how gitflow works, but the problem we have is that it's confusing to have develop and master pointing to different commits which are essentially logically identical. It can also make CI pipelines inefficient since it may cause an extra unnecessary identical build. Is there a variant that merges release to master, then master to develop? – Sororicide

@Sororicide - I'm not sure what to tell you. You find the merge commits confusing and feel they get in your way; many teams don't see it that way. "...it's confusing to have..." is not a statement of fact, so you'll have to excuse that I'm not inclined to debate someone who presents it as one. If you don't like getflow, use something else. There is no magical registry of merging strategies from which you're required to pick; figure out what works for your team. – Metagnathous

Well the OP has asked the question to clear up their confusion. And it is confusing to me also. They also made some good points in the comments about why they are confused and so have I. If you disagree with our opinions then that's completely fine. Debating whether it is confusing is futile here anyway, that is how git-flow works. – Sororicide

Actually, there's a problem with git describe when you merge the release branch instead of master into develop. Even the creator of gitflow said that he should fix it, but he never did. See my answer for more info. – Honourable

Answer 3

TL;DR: you should back-merge the release tag (or master) into develop, instead of 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 there'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

Honourable

Answer 4

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.

Marijn