Git server administrators face a bit of a challenge. The high uptake rate of Git means that there are thousands of developers who are not really familiar with Git, and who therefore may be running Git commands that cause irreversible or highly disruptive changes to the Git repository. Furthermore, Git itself does not help much with this; whatever access controls it has, apply to the entire repository, and cannot be made more fine-grained.
For instance, the master branch in most projects represents the most stable code. Yet, a junior developer can easily run a command such as git push origin +master, (which pushes the developer's local branch onto the server) and thus overwrite weeks or months of hardwork by the rest of the team. People with deeper Git expertise can probably recover the lost commits, but it would certainly take time and effort.
Worse, Git's command syntax sometimes makes it worse. For example, the command to delete the master branch is only slightly different from a normal push, that is, git push origin :master (notice the extra colon?).
The most common need, therefore, is to prevent these kinds of accidents: overwriting (or rewinding) one or more commits, and deleting a branch or a tag.
Git itself does provide some measure of protection. You can set the config items receive.denyDeletes and receive.denyNonFastForwards to true. Unfortunately, this is a bit of a blunt instrument—now no one can delete or rewind any branch!
In larger setups with several repositories and several developers, you may also be concerned about allowing everyone to read all repositories. Or it may be that some roles (such as a test engineer) should not need to write to the repository; read-only access is sufficient. Up to a certain point, this problem can be solved with Unix permissions and user/group permissions applied judiciously. Perhaps even POSIX ACLs can be used if you're comfortable with that sort of thing.
However, using POSIX ACLs and user/group permissions has several disadvantages:
Each Git user needs a corresponding Unix user ID on the server.
Managing access rights can only be done by using the
usermodandsetfaclcommands.Checking the current set of permissions is not straightforward. You will need to run multiple commands and correlate their output manually.
Auditing changes in permissions over time is impossible because no history is kept by the system.
These disadvantages require a lot of effort to manage even a few repositories and users, and even a modestly sized setup would quickly become unmanageable.