How does Git differentiate changes to a file during a merge commit from the same changes done to the file in a normal commit?

Question

Consider I have made changes to a file in a personal branch, and I want to have my branch merged into another branch (say, development). If someone else has also made changes to the same lines in the file which I've affected, there will be a conflict that I need to resolve before my branch can be merged. I usually will do a git pull origin development, at which point Git will call out the conflicts and allow me to fix them. After I fix them, if I've opened the file manually without using git mergetool, I need to git add the file to "mark it as resolved," and then I do a git commit and accept the default merge-commit message.

At this point, the changes I've made to the file become the single source of truth and will override the changes which have been made in the development branch, so hopefully I haven't clobbered that person's work.

My question is, how does Git know that this is a merge commit? I'm thinking it must know, because if I made the exact same changes to the file which I made during the conflict resolution and then did a git add and git commit, it would by definition be a conflict. Please correct me if my assumption is incorrect. I was led to this question in my mind because I wondered why I need to take all of the branch differences into my branch in order to resolve one simple little conflicted file.

Answer 1

At this point, the changes I've made to the file become the single source of truth and will override the changes which have been made in the development branch, so hopefully I haven't clobbered that person's work.

The “overriding” happens at the time of the merge commit on your branch. Merge commits are commits that have multiple parents, containing information on how to resolve conflicts. When you merge your branch back into development, it’s not that your branch has become a “single source of truth”; it’s that the conflicting commits from development already exist in its history. There are no further changes development made that your branch didn’t, and nothing needs to be overridden.

So, to answer what you pointed out as the question directly:

My question is, how does Git know that this is a merge commit?

Git can know that something is a merge commit because it has multiple parents, but it doesn’t have to know that here to begin with, because the reason there aren’t any conflicts in the merge back is not that a merge commit takes precedence over a normal commit.