As saxo said, these two options can (and sometimes do) work in tandem:
--bare makes a bare repository, i.e., a repository with no working tree.
--shared=mode makes sure that Git uses Unix-style permissions on its own internal files according to the mode argument. This is not likely to work on anything that is not a Unix-like system, but since Linux is a Unix-like system, it works well on Linux servers.
A bare repository—one with no working tree—cannot have any work done in it. This makes it an ideal recipient for work done elsewhere. That work-done-elsewhere arrives at the server computer via git push.
A non-bare repository can have work done in it. Suppose someone has logged on to the server, and is performing ongoing work in the non-bare repository. Suddenly, someone on some other computer runs git push server branch. This is a request that the server accept new commits and update its (the server's) branch named branch. But the person who is working on the server is in the middle of making updates to that same branch. How will Git reconcile the incoming updates with the logged-in-on-the-server-user's updates? The answer is: It won't. The server Git will refuse the incoming update, because some user is potentially doing work on the server.
Since a bare repository has no working tree, it is impossible to do any work in it. Therefore, no one is working on this bare repository on the server. Therefore it is safe to accept an incoming push. Conclusion: non-bare = not-safe; bare = safe. A --bare clone, on a server, can accept pushes. Hence, server clones are normally bare.
The shared stuff is much more complicated. Given that you have a Linux server with a bare clone, we now ask: Who has access to this Linux server? How do they log in to the server? Does this affect their ability to use git push? The answers here vary, hugely. For instance, the servers that GitHub run don't allow users to log in at all, but do allow, via specialized tricks, ssh push access, as long as the users push as a pseudo-user named git. This method bypasses all the normal Linux security stuff, and the --shared mode stuff becomes irrelevant.
Other systems, however, do allow users to ssh in. Some users have full access as themselves (so that they can use sudo and/or do other administrative tasks directly on the server). Other users may have more limited access, but still as themselves. They "log in" on the server and have a user ID, and with that, user and group IDs and accompanying permissions.
The Linux permissions model allows Git to work with the Linux group-permissions model, provided that the Git repository itself contain group-writable directories. Since Git creates new directories on its own (during, e.g., git push operations), these newly-created directories must have the correct permissions—specifically, group-write permission (and correct group ownership, which is managed separately, not by Git). To make this happen automatically, the adminstrator should create this repository with --shared=group or similar.
