Is the commiter of the git is the real person who did the push ...?
No.
Every commit stores some metadata. Here is a recent commit to the Git repository for Git, for instance:
$ git cat-file -p HEAD | sed 's/@/ /'
tree 8ccb7d4fa49449a843b00aca64baf99feb10e2ab
parent e7e80778e705ea3f9332c634781d6d0f8c6eab64
author Junio C Hamano <gitster pobox.com> 1516742470 -0800
committer Junio C Hamano <gitster pobox.com> 1516742470 -0800
First batch after 2.16
Signed-off-by: Junio C Hamano <gitster pobox.com>
As in the other answers, the author string is intended to describe the person who wrote the code in question—the code itself is under the tree—while the committer string is intended to describe the person who stored the code in a repository using the git commit verb. Neither has anything to do with a person who ran git push, because you don't create a new commit using git push.
The git push verb is for transporting existing commits (and/or other Git objects) from one repository to another. The git fetch verb does the same kind of thing, except that the direction of transport is reversed. (And remember, git pull just means: Run git fetch, then run a second Git command, usually git merge.) If you wish to record the identity of someone running a transport command like git push, you need to use or augment your transport software (ssh, secure web server, etc) so as to record this information.
Note that the person who creates a commit has complete and total control over what goes into the new commit, including both author and committer strings. These strings are not automatically authenticated. If you wish to authenticate them, you can make additional requirements on the message data—the text after the first blank line in the commit object. (This is not part of Git itself, though Git knows how to run PGP commands that create or verify digital signatures. The example commit above does not have any such digital signature.) When you are receiving commits and/or other Git objects, either as the recipient of git push or the initiator of git fetch, you have some control—via Git's hooks for push-recipients—over whether to accept the new objects. (As the initiator of a git fetch you don't have any hooks, but you have complete control of the repository both before and after the fetch.)
Summary
The git commit verb creates new commit objects (and, often, additional Git objects). The committer is the person who runs git commit—and as the committer, that person chooses the strings to be used here. The author is the same person, unless the committer chooses otherwise.
The git push verb activates a transport system, usually via SSH or HTTPS (though Git cares only about transporting data, and you can even use git bundle to split the transport into "write" and later "read" phases so as to transport the data on punched-cards or whatever other crazy system you like). The transport system carries existing commits and other Git objects from one Git to another Git. To make the transport as fast as possible, if the connection between the two Gits is interactive, the two Gits can exchange information about which commits and other objects they have, and hence figure out who should receive which objects that they don't have.
It's up to the recipient to do any verification required. Often, there is none: if the transport itself is authenticated, the receiver simply trusts the transport's authentication. Since commit hash IDs form a Merkle tree, the transport-specific authentication is often sufficient.
