Gitflow develop branch behind master after a release

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

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.