Depends on how you define "all the information": contrary to centralized systems, in Git, pushing is a voluntary act -- just like sharing, -- where the one who shares decides what they want to share. In the case of Git, a developer chooses which bits of their local commit graphs to send, and which objects to update with them.
* If you have recorded 10 commits on top of your local branch "X" which tracks a remote branch, you're not required to update the branch being tracked with all those 10 commits -- you might send, say, just the first three of them.
* Tags are not pushed unless
git push is explicitly told to do that, and the tags to send are specified. Notes are not sent as well.
* New local branches are not pushed unless
git push is told to do so.
On the other hand, what's sent, is sent completely and with all the dependent objects, so if someone pushes a commit into the repository, you can be sure everything this commit references in the repository it
has been created in, is also sent.
Note that what I have just described -- the freedom of the owner of a local repository in what they share -- is just a property of a DVCS you have to live with. But what ends up in your centralized ("shared") repository is self-consistent, and you can safely back it up.
What's pushed when a developer simply runs
git push or
git push in their repository is another story completely as it depends on a number of details. If you're interested about this, ask away.
I can see somehow the name of the files and their content in the git repository that saved on the git server?
Yes: the regular Git commands for inspecting the commit graphs work in bare repositories just as well as they do in "normal" ones.