6

I've banged my head against the wall with this Github issue enough to finally come here for help. My repo has two branches of interest: master, which is the currently live release branch, and alternate-testing, which is exactly what it sounds like. Our dev process has feature branches regularly branched (and forked) off alternate-testing, then merged back into alternate-testing. Finally, alternate-testing is periodically merged into master. Note that the testing branch is the gatekeeper to master - nothing gets into master but by going through alternate-testing.

To be perfectly clear, this is not a situation like this:

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [master]
       \                      /
        A -- B -- C -- D -- E [alternate-testing]

as in this question, because master never changes by itself. A more relevant diagram is:

1 -- 2 ---------------------- * -- 8 [master]
       \                      /
        A -- B -- C -- D -- E [alternate-testing]

So at the end of this diagram, master and alternate-testing have to be identical. There were no changes to master after the branching, and every change in alternate-testing has been merged into master.

Yet, GH shows that the two branches are out of sync. I just did the merge this morning, and GH says about master: "This branch is 3 commits ahead, 29 commits behind alternate-testing."

How is this possible, and how can I fix this maddening problem?

Dr. Andrew
  • 2,532
  • 3
  • 26
  • 42
  • I just cloned your github repository and your alternate-testing branch has changesets not in master, are you sure you've pushed or similar? After I had merged alternate-testing into master, my local clone is now 33 commits ahead on master compared to your GitHub repo. – Lasse V. Karlsen Mar 29 '17 at 14:03
  • I also see commits with a comment like "Merge last for now ... feature update (#241)" which is definitely not a merge, since it only has 1 parent. Are you sure you're not doing odd rebase stuff or similar to your repository as the history definitely looks odd. – Lasse V. Karlsen Mar 29 '17 at 14:08
  • Just for giggles, execute `git config branch.autosetuprebase` and tell me what it says, if anything? – Lasse V. Karlsen Mar 29 '17 at 14:09
  • What commits do you see in alternate-testing not in master? Re. your 2nd comment, there are several PRs that I merged, then had to un-merge, since I needed to get in more changes, but couldn't because of this problem. The git config command returns nothing. Also everything we do with master/alternate-testing is done through PRs on github - nothing is ever pushed directly to either branch. Bottom line: note the last statement in the question: "This branch is 3 commits ahead, 29 commits behind alternate-testing." After this branch, master should not be behind - at the very least. – Dr. Andrew Mar 30 '17 at 04:25
  • Also, if you do the branch comparison again, you'll see every commit listed as needing to be merged is exactly what was already merged into master with the last PR. – Dr. Andrew Mar 30 '17 at 04:34
  • 2
    But it *is* behind because there exists commits that haven't been merged into it. The fact that the changes introduced by those commits are already present is irrelevant, git doesn't analyze the changes at all, it just says "I can see commits you haven't merged in". – Lasse V. Karlsen Mar 30 '17 at 06:32
  • based on the repo from github, it always merge from `master` into `alternate-testing` branch which is opposite with what you described in the question. And what's the commit id of these two branches since I can't get the message (3 commits ahead, 29 commits behind) from the github repo? – Marina Liu Mar 30 '17 at 14:56
  • Lasse: your comments were spot on. The issue we were facing was caused by the Squash, which creates a new commit in the base branch but not PR branch. Thanks. – Dr. Andrew Apr 05 '17 at 06:14

1 Answers1

5

Thank you to the commenters for helping point me in the correct direction with this. We had been merging our PRs with a Squash+Merge, which has the benefit of simplifying the commit history.

The Squash works by creating a new commit which then gets merged but only into the base branch. Hence, while the code in the base branch is identical after the merge to that of the PR branch, the base branch has an extra commit. It seems that GH should put the squash commit on both branches to maintain the real history.

We have solved this by using a plain vanilla Merge, rather than the Squash+Merge.

Dr. Andrew
  • 2,532
  • 3
  • 26
  • 42
  • Thanks! that cleared things up. So the only way to make sure Github sees the two branches are up to speed is to redo the PR but with a plain merge without squashing? – jlos Sep 14 '17 at 20:21
  • Yes @jan -vansteenlandt - that is how we fixed the issue. – Dr. Andrew Sep 16 '17 at 07:36
  • Thanks for confirming! I started using squash and merge because we're merging branches with discrete features quite often and it's easy to rollback a specific merged branch when using squashing. I think squashing and merging is really useful when working with forks for example, perhaps a little less so when working within your own repository. – jlos Sep 17 '17 at 08:00
  • Right. It also depends, I think, on the type of project development workflow that's used. – Dr. Andrew Sep 18 '17 at 08:13
  • Just one thing to note: If you want to keep the `master` clean try to Revert the Squash merge using Squash again and only then use a Plain-old Merge to merge your other branch to `master` – Islam Aug 24 '18 at 02:40