My VSTS pull request shows diffs between two branches when none exist

Question

I'm trying to understand what's happening here because this is tripping me up.

Let's say I have two long lived branches. () - Master and [] - Develop. The current state of my repo looks like this:

() <-- Master \ \ []--[]--[] <--Develop

I introduce a {} - hotfix branch off master with changes that need to go into both Master and Develop.

()--{} <-- Hotfix (needs to go into both Master & Develop) \ \ []--[]--[] <--Develop

I merge hotfix into both Master and Develop via separate Pull Requests.

   _ _ _ _ _
  /         \
 ()----{}---() <-- Master /w hotfix changes
   \    \_ _ _ _ _
    \             \
     []--[]--[]----[] <--Develop /w hotfix changes

At this point I notice two things in VSTS' pull request diffing UI:

• If I create yet another pull request for hotfix into Master or Develop (recall that both long-lived branches already contain the hotfix changes from a prior PR), the web-based diffing UI still shows a diff between hotfix and Master or Develop.
• If I create a pull request for develop into master, it shows a diff of the changes contained in hotfix (but those changes are already in both Master and Develop).

What's going on here?

Answer 1

The main point is how VSTS complete a PR for a fast-forward merge.

Assume there are two branches (branch1 and branch2) with below commit history:

…---A   branch1
     \
      B  branch2

If you merge branch2 into branch1 by default manner (fast-forward), such as by executing git merge branch2 command directly, branch1 and branch2 will point to the same commit B as below:

…---A---B   branch1, branch2

But for VSTS, it complete a PR with no-fast-forward, as the command git merge --no-ff. So even it’s a fast-forward merge, there will create a merge commit.

So if you create a PR to merge branch2 into branch1 (or use the command git merge branch2 --no-ff), the commit history will be:

…---A---C   branch1
     \ /
      B   branch2

While if you create a PR to merge back branch1 into branch2 in VSTS (actually it's unnecessary), it allow you to create the PR since the commit C from branch1 is not on branch2.

Now go back to your situation, the commit history original as below:

  H1  hotfix
 /
M1    master
 \
  D1---D2---D3  develop

When you first create the two pull requests to merge hotfix into master and hotfix into develop separately, after completing the two pull request, the commit history looks like:

M1-------M2    master
 \      /
  \---H1----------   hotfix
   \              \
    D1---D2---D3---D4  develop

So if you create another PR to merge master/develop branch into hotfix, VSTS will allow you to create the PR since master/develop branch and hotfix branch are point to different commits. But it’s actually unnecessary to merge the changes back.

And it you create a PR to merge develop branch into master branch, it not only shows the diff for commit D1, D2 and D3, but also show the diff commits M2 and D4 (even though they contains same changes from hotfix branch) since they are different commits.

BTW:

• Based on your workflow, master is the main branch, and all the works are developed on develop branch. When it’s ready, merge develop branch into master branch.
• For bug fixing, it does need to branch off hotfix branch from master branch. But when fix the bug on hotfix branch, you’d better merge hotfix into develop branch, and then merge develop branch into master branch. This can make the history more clearly.