Git PR Merge and Resulting Branch is Different

Question

TL/DR: We merged git branch master into production and the resulting source code was different. Why?

Using an Azure DevOps Pull-Request we merged (FF) our master branch (at commit 01785665a ) into production , deployed production to PROD and went home feeling sure that we'd achieved our goal of pushing staged and tested changes on master to production. Imagine our surprise when we discover production is not identical to staging but has some old code.

How can 2 branches be merged and not be identical?? The last commit 01785665a on master has my latest changes and is correct but these changes are NOT in the merge commit of c1aa29bda ??

Judging from the DevOps diagram below we did not merge in from master but some commit c503afc9 (from Apr 27) but perhaps Azure Devops has a confusing graphic (it's not clear which branches the vertical lines refer to). The other graphics show master 01785665a being merged in.

Git is convinced that production is up to date with master: git merge master (on production) => Already up to date

git log (production)

commit c1aa29bda... (HEAD -> production, origin/production)
Merge: 2095cbd 0178566
Date:   Wed Jun 3 10:14:15 2020 +0000

    R4 Release

git log (master)

commit 01785665a... (HEAD -> master, origin/master)
Merge: bdc6c56 a5e1d32
Date:   Wed May 13 11:03:43 2020 +0000

    Merged PR 13135: v1.6.6 ...

Answer 1

So it sounds like you didn't want a merge in the first place. And it sounds like you didn't need a production branch either: It seems that what you're trying to say is, "Hey, world, see this commit on master , namely 01785665a ? That is our "Release 4".

(That is not what you did say. What you said was: "Take some aspects of the existing master branch and some aspects of the existing production branch and mix them together and make a new hybrid thing called "Release 4." That's what you said, because that is what merge means. But it seems that that is not what you meant.)

The way to say what you appear to want to say is to tag this commit. For example, you might tag it as r4 , meaning "Release 4". Now you know that in order to test or release Release 4, you checkout r4 and archive it.

Henceforth the master branch may grow, but the special feature of a tag is that it remains forever attached to that one commit. So r4 will stay right where it is, and you can check it out and return to it at any time.

Answer 2

The issue is solved by pushing a new commit to master branch, and then merging to production branch.