Lets suppose I branch of from master (A) and make a commit there (B) and then a commit on master (C) and then merge them (D):
B
/ \
A--C--D master
Now is there something that sets C apart from B (that makes it on the master branch)?
In Git, commits are organized in a data structure called DAG (Directed Acyclic Graph), where each commit only points to their parent(s) (that's why directed), and where there is no route that starting from a commit leads back to the same initial commit (that's why acyclic).
Branches in Git are just implemented as a file with the SHA1 (the ID) of the head commit (the tip) of a branch. They're merely pointers. If you go under .git\refs\heads and open any branch file with a text editor, you would see the SHA1 of the commit they point to.
The heavy lifting that holds together the entire structure (the history of changes) is done by the commits themselves and by how they're organized. Branches do not have any special meaning or functionality. They're just a human-readable and convenient way to refer to the latest changes on a development line.
So, to answer your question
Now is there something that sets C apart from B (that makes it on the master branch)?
Commit objects alone do not have any properties that say whether they are on a branch or another, like a branch pointer. However, their histories (so, sets of commits as a whole) can tell whether they belong, or belonged, to a same line of development or not. Therefore, you could actually tell B and C apart if you ran git log with the --first-parent option.
git log --first-parent
Running this command from the master branch will show you commits D, C, A but not B, as only the formers happened on the history of the first parent (master), while B happened on the history of the other branch.