How to resolve merge conflict during pull request?

Question

We generally have individual branches off of master. So for example we have a branch named "JohnMaster". John does his development locally off of JohnMaster and when he is ready to push his code to master he pushes his branch to remote and then does a pull request to master from JohnMaster. The problem were running into is we have conflicts when doing the pull request.

The way i thought we could resolve the merge conflict was to bring master down and the do a rebase locally from master-->JohnMaster and then resolve the merge conflict during the rebase. After doing the rebase it wouldn't let me push my code back up to remote because it said i was 2 commits off of remote (before the rebase they were identical) but when i do a git pull i get another merge conflict.

I know probably the best practice is to do a pull request from master-->JohnMaster (reverse merge) and then do a git pull when on JohnMaster before you ever push your commits up to remote but sometimes people forget and then we run into this issue.

So my questions are:

1. Why does rebasing locally not work?
2. How can we get around this issue?

Please note we can't commit directly to master. There is security on the branch that requires pull requests.

Answer 1

Short answer:

Merge origin/master into JohnMaster and push this to its remote (origin/JohnMaster). Now you can do the pull request from origin/JohnMaster to master and you won't get merge conflicts as long as there are no new commits on master (commits in master that are not contained on JohnMaster)

git checkout JohnMaster
git merge origin/master
#solve merge conflicts
git commit
git push
#pull request
git push

Long answer

If you run git rebase origin/master what is actually happening is that commits that were added to JohnMaster are rewritten (in your case two commits) and put after those from master. E.g. since JohnMaster branch was created B and C have been added to master and B' and C' have been added to JohnMaster. After rebasing you get A --> B --> C --> B'' --> C''. Before the rebase you had A --> B' --> C' on your feature branch and you still have it on the remote branch before pushing. At this point Git tells you that you don't have locally B' and C' because they have been rewritten to B'' and C'', therefore different commits.

At this point, you could force push your local rebased history with git push -f. With this you eliminate remote commits B' and C' and you get the same as you have locally on origin/JohnMaster, this is A --> B --> C --> B'' --> C''. Now you do your pull request and if it is accepted you exactly this commit history on master branch.

Personally I don't like rewriting remote, already pushed history and I think it should be avoided whenever possible, but it is actually an option you have.

If you merge origin/master into JohnMaster (this is the prefered way in my opinion) you leave all the existing commits as they are: A --> B --> C and A --> B' --> C' and you add a new merge commit M where the two branches come together again. A merge commit is a commit with two parents, in this case C' and C. You can push this merge commit safely without force pushing.