Menu
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?
447
No, merging does only affect one branch.
In a good workflow, the feature branch is deleted once its merged back into master. New branches should be created for each new feature(s) that you work on.
Merging Branches. Once you've completed work on your branch, it is time to merge it into the main branch. Merging takes your branch changes and implements them into the main branch. Depending on the commit history, Git performs merges two ways: fast-forward and three-way merge.
There are times when you get an “not fully merged” error for a git branch, usually when trying to delete a local branch from your machine. It's a safe bet that something in your local branch has not actually made it to the remote repository and we should do some investigating.
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.
114
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
