Merge conflicts on GitHub, not locally?

GitHub Help How to use Git and GitHub
#1

Hi - recently my team has encountered an issue where when we open a pull request, GitHub will state that there are merge conflicts between the branches preventing the merge, but if we pull the relevant branches and merge locally with command-line git (with --no-ff option), no conflicts are detected. We have pre-commit linting hooks on our repos so I don’t think the problem is due to whitespace conflicts, etc., and sometimes legitimate conflicts do exists, but most of the time there are no perceivable changes between the conflicted files.

Has anyone else encountered something like this happening? Any help would be appreciated. Thanks!

8 Likes
#2

Hi @pcurc,

I’d recommend checking out our Help Doc on how to resolve merge conflicts specifically on GitHub. You find that here:

https://help.github.com/articles/resolving-a-merge-conflict-on-github/

That article contains information on how to solve merge conflicts on GitHub, and also what to try if those initial steps aren’t working.

I hope this helps!

#3

Hi @pcurc,

Sometimes this can happen because of how GitHub compares branches versus how Git compares branches. GitHub compares branches from the point where they are created whereas Git in the command line generally compares branches from where they are currently.

Therefore, if you have a master and a develop branch and you create a Pull Request at a certain point in time to merge develop into master but then master continues to evolve in a way that resolves a conflict before it would be created, you can get a merge conflict warning in the web interface when you wouldn’t via the command line.

I don’t know if that’s what is happening to you, but if it is, I hope that context helps to explain it.

Thanks!

5 Likes
#4

It sounds very likely that this is the explanation for what’s going on. My question would be, is there anything we can do about this, other than changing our branching strategy?

Briefly, this is how things work:

* Feature branches are made off of master

* Feature branches then merged into develop for testing

* Upon acceptance, feature branches are merged into master for release

* Post-release, master is merged back into develop to get the merge commits from master in there

Thank you for any suggestions!

#5

Other than changing your branching strategy, I’m not sure that there’s any direct workarounds for this. The way that we handled this flow at the last place that I worked is that feature branches would be made off of develop and then merged back into develop for testing which would then be merged into master. It allowed us to have the fewest conflicts with the most test coverage. I understand that this may not work for you, however.

#6

We’re having the same exact problem and changing the branching model isn’t an option when working in a continuous development model where master is always the most reliable source and all other branches are disposable and possibly corruptable by some mistake. 

I’m surprised this problem isn’t more widespread. 

4 Likes
#7

We observed this issue between feature a7dc88d and master ec96c64bf in this PR https://github.com/hail-is/hail/pull/4307. We use a CI/CD system that had tested and verified this PR and then tried to use GitHub’s merge endpoint, but GitHub rejected the merge, claiming it was not mergeable. All of these succeed using the recursive merge strategy:

git checkout master
git merge feature

git checkout feature
git merge master

git rebase master feature

Obviously, this makes us concerned that git isn’t using the same merge strategy as us thus potentially invalidating our testing.

#8

Hi @danking,

It looks like that PR has been fixed since you posted this, so I’m thinking all is well at this time. Is that correct? 

#9

For what it’s worth, we’re having the same issue.  Github’s approach to merging conflicts causes us great difficulty–we are forced to merge all conflicts on the command line because our workflow does not support polluting a feature branch with dev branch content (for us, dev is where separate developers’ code meets for the first time, and often contains code not considered ready for production).  The Github approach forces dev-branch content to be merged into feature branches, which then means those feature branches cannot be merged to production because they now contain dev-branch content.  No option is provided in the Github interface to resolve these merge conflicts, and what’s worse is that after the merge conflict is resolved locally, Github does not resolve the merge conflict when those changes are pushed to remote (i.e. Github itself).

The desired solution would be to provide options, within Github, specifying how merge conflicts are handled, instead of forcing us to merge the pull-request target (“base”) branch into the source (“compare”) branch.

2 Likes
#10

I just had this same problem.

I think it might have been caused by using the GitHub PR ‘This branch is out of date’ UPDATE/MERGE button.

Solved the problem by running git command line merge i.e. 

git merge master

In future I will use command line instead of GitHub PR merge to avoid this problem.

2 Likes
#11

I had the same problem and learned from experience that I should merge from master to my dev branch on my machine so that I can resolve the conflicts on my machine rather than letting GitHub do it (GitHub conflicts resolver looks completely unusable to me).

#12

I had a similar problem in the following case:

  • Branch A is based off Master and has commits X, Y, Z

  • Branch B is based off Branch A and has commits X, Y, Z, P, Q; so that only P and Q show as part of this PR

  • Squash-merge branch A into Master

  • Rebase Branch B from new Master, dropping X, Y and Z, leaving P and Q

  • Force-push the rebased Branch B, now just P and Q, and change its base to Master

  • Try to squash-merge branch B into Master, run into this problem

What happened was, somehow Github got stuck in an in-between state, reporting merge conflicts on the remote as if I was trying to merge a squash-merged Branch A into Branch A despite having completed the change of base branch. These conflicts didn’t actually exist so couldn’t be resolved, locally (merging Master into Branch B was a no-op) or through GitHub’s interface.

What fixed it for me was changing the base branch again, waiting a bit, and changing the base branch back again. I think maybe something got snarled up and stuck because I changed the base branch too quickly after force-pushing the rebase.

#13

Actually,  I’ve also this problem Please if anyone found any solution the Merge conflicts then Please let me know also

Thanks

#14

Ran into this issue as well…

I have the following branches main, A, B.

  • A is based off main
  • B is based off A

I merged A into main with rebase and merge and after that GitHub says B cannot merge into main because there was merge conflict… So I tried to pull the latest main into my local dev machine and tried rebase B onto main locally and it worked without any conflicts… WAT?!

There are no other branches or merges involved at all.