0

My scenario is this:

  1. I have a development branch (dev), and a production branch (prod) in Github.
  2. In my CLI, I branch off of prod, checkout a set of changes from dev, and merge the changes into prod (and push to Github)
  3. In the Github web UI, if I then create a pull request to prod with dev as the source, it does not show the changes that I already picked out of dev; it seems to be following the logic that dev has never been merged with prod, therefore ignoring the changeset which I just picked out of dev and merged with prod.

Can someone explain the logic behind this? It is extremely confusing for my team, because we regularly check out changes from dev and merge them to prod, yet Github shows all those differences as not yet merged in the pull request from dev to prod. So it appears to us that the dev branch is massively out of sync with the prod branch, when in fact, the prod branch contains most of the dev changes already.

Noting that the git CLI reflects the changes as expected: I see close parity between dev and prod when comparing the two branches on the command line. It's the Github web UI that seems to be following its own logic.

leomercury
  • 3
  • 2
  • 1
    First problem that I see is that you are pushing into _prod_, not another separate branch. And what do you mean exactly when you say `checkout a set of changes from dev`? – eftshift0 Apr 28 '21 at 13:05
  • I'm confused by this: in #2 you are merging `dev` into `prod` manually and then *push* it out. At that point `prod` now has `dev` in it. In #3 you're creating a PR for `dev` into `prod`, but you already did that in #2. Why are you doing the same thing in #2 and #3, first manually and then with a PR? Note, normally you would *only* do #3, and if you did #2 it would be only to test the merge, but you would not *push* it out. In fact, most repos wouldn't even *let* you push out important branches, as they would be locked down to only allow PRs. – TTT Apr 28 '21 at 14:49
  • please post the set of command you type, step by step – St3an Apr 28 '21 at 18:41
  • @eftshift0 the process is to branch from `prod`, check out files from `dev`, and merge them in. @TTT since we have a lot of changes frequently, we use the pull request tool to try and see what's not been checked into the `prod` branch using `dev` as the source, to get a handle on what we might have not addressed. It seems the way that we're doing this is probably not standard. – leomercury Apr 28 '21 at 19:29

1 Answers1

0

In a pull request from dev (source branch) to prod (target branch), or in a merge request of Gitlab, or in a pending change of Gerrit (a bit different from the 2 others), the differences displayed on the UI are the result of git diff prod...dev. About the difference between git diff prod..dev (equivalent to git diff prod dev) and git diff prod...dev, read this question.

prod...dev compares the merge base of dev and prod against dev. The merge base of dev and prod is the latest common commit of the 2 branches. You can get it by git merge-base dev prod. The merge base can be considered as the fork point where dev is branched off prod or vice versa. It shows what codes have been changed since the fork point on dev.

Suppose you create dev from prod at a commit and later work on it. Before you merge dev back to prod, other developers could be constantly updating prod. To see what you have changed since the fork point, git diff prod dev is not a good method. Consider an edge case in which prod has been updated by others to a state exactly the same with your dev. If it uses git diff prod dev, nothing is printed as they have completely the same codes. It's unfair to say that you have done nothing. However, git diff prod...dev displays your work.

To display the difference on the UI as you expect, you could run git checkout dev && git pull origin -r prod && git push origin -f dev to rebase your dev onto the latest prod. This way, the new merge base is exactly prod. And now git diff prod...dev and git diff prod..dev have the same result.

ElpieKay
  • 27,194
  • 6
  • 32
  • 53
  • I think I understand now. Github's UI is showing the changes/difference between the most recent common merge bases between the two branches. The way we are doing things: branching off of prod, checking out files from `dev`, and merging then into `prod` does not leave any trace of a merge between `dev` and `prod`. That is why the pull request UI shows such a large changeset when we try to see what differences "remain" between dev and prod. Using `git diff` has been misleading, at least in terms of how I have been interpreting the results. – leomercury Apr 28 '21 at 19:24