Git PR Merge and Resulting Branch is Different

0
votes

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

azure devops graph

VSCode git graph

Git Extensions Graph

2
gitmergeazure-devops
You've hidden all the info, so it's hard to help. But do you know what a merge is? I mean, let's look at your merge commit: it has two parents, 2095cbd and 0178566. You have not shown either of those commits in your graph (though the second one is clearly master). But do you understand what it means to make a merge commit from those two commits? Maybe your expectations are wrong. – matt
In any case, it would help a lot if you could get specific. Since git lets you look directly into a commit, do that. Look into commits 2095cbd and 0178566 and examine the contents of some individual file that you are troubled by in the outcome on production. Tell us what's in that file in 2095cbd and what's in that file in 0178566 and what's in the file in the outcome in production and let's talk in specific terms about why production came out that way. – matt
I'm not sure why you need more details - suffice it to say that I expect the contents of ALL files to be identical after a merge. Am I hopelessly off base here? Or is a merge the wrong approach to me wanting to freeze the state of master onto the HEAD of a new branch production so I can deploy HEAD of production and have a history of what I deployed? – Marc
I don't need more details, except in order to understand what you mean. You keep using the word "identical". I don't think it means what you think it means. :) Identical to what? This is a merge. There are two different branches involved as parents. The resulting merge commit is not going to be identical to either of them. If it were, this would not be a merge with two parents. That is why I am suggesting you give a specific example of what you expected and what actually happened, so that we can straighten out the issue. If you don't want help, don't do so. – matt
When I use the word "merge" in this context I mean: take the state of all files on master and copy them to production so production is identical to master. Is merge the wrong tool for the job. Do you understand what I am trying to accomplish? namely: copy this "version" of the branch to another branch for later reference. – Marc

2 Answers

0
votes

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

1
votes

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.