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).

CodePudding user response：

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.

CodePudding user response：

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.

Please note that you may be updating multiple branches at the same time when calling git pull --all, so there may be multiple conflicts as well.