'Resolving git pull merge conflicts
Is it correct that for git pull (and thus git merge by extension) to throw merge conflicts, the local and remote repositories have to be out of sync ? Basically, is it necessary for these 2 conditions to be met in order to get a merge conflict -
- There must be at least one commit made locally that hasn't been pushed to remote.
- There must be at least one commit made on remote (that hasn't been pulled yet) that involves the changing the same line of code as one of the commits made locally (that hasn't been pushed yet).
Solution 1:[1]
Pretty much correct.
As for the merge: Certainly there must be a commit on your side that the remote doesn't have; otherwise we'd fast forward, which is not really a merge. And there must be a commit on the remote that you don't have: otherwise nothing would happen (you'd be up to date).
But that is merely the prerequisite to get a merge in the first place.
As for the merge conflict: It doesn't have to be the same line of code, it could be an adjacent line. And there are other ways to get a merge conflict, like one side deletes the file entirely.
What matters, however, is not "one of the commits made locally". It is the totality of what has been done on each side since the last common commit. If you had a commit that edited the same line he edited, and then you had another commit that changed it back again or changed it to what he has, there is no conflict.
Solution 2:[2]
Yes, both repos must have at least one unsynchronized commit each that changes the same lines. Otherwise, the most up-to-date change in the remote branch will be transferred to the local clone without a conflict.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 |