问题
Is there any way to ensure who is actually the committer to our Git repositories? We have each developer's keys in CloudBees, so that ensures that it is one of them, but is there anything stopping one developer from inputting another developer's name/email in the commit field? If not a way to stop them, is there a way at least to determine the committer's SSH key from the Git logs?
回答1:
No, Git itself has no built-in mechanism to ensure that the committer is actually the one that is stored in the commit object. There are actually downsides to have such a restriction. Git is a distributive version control system, so commits are distributed to various places, and not necessarily collected in a central place. Even if there is a central repository that is used to collect all the stable (or whatever) changes, it’s still perfectly fine to transfer changes in other means than through said repository.
For example if developer A and B both cloned from the “central” repository, it is still possible for A to for example work on a few things, then send these changes explicitely to B to review without going through the central repository (for example by pushing to B’s repository, or B pulling from A’s). Imagine B then bases some commits on those changes and then wants to publish it to the central repository, without having A push his own changes there first. If there was some restriction in place to only allow changes you committed yourself, then B wouldn’t be able to push A’s changes in that situation.
As such a workflow is very common in a real distributive workflow, such restrictions are usually not applied. However I can still see why one would do that, probably restricted to just a small number of new developers or something.
There are indeed some ways to enforce such a restriction. Note that Git itself won’t be able to check anything based on SSH keys. Git has a simple protocol and all the authentication and authorization is never handled by Git directly (Git does not support any of it). For example SSH access to repositories is handled by the standard SSH access rules of the operating system; and for https access, the http server handles the authentication.
A common access layer for Git is Gitolite. It controls access over SSH using a single user. Essentially it restricts the user’s access based on its SSH key to a very small Git-specific set of commands. You could write your own plugin for it that will require commits to always have the same committer as the pushing user; or you could use the already implemented feature using email addresses which it ships with. For that see the section “checking author email” in the manual.
Btw. the usual way to ensure that a commit’s committer is actually the one it says it is, is by signing the commits. While it does not prevent committing as someone else, it will allow you to check the identity of a committer.
回答2:
You can use Gitolite to control access to your repository; Gitolite provides tools for adding much finer grained controls over who can access individual repositories or branches, and who can update which files. It also allows you to log which user pushed which changes.
Using regular Git via SSH does not allow you to do this, as it only uses Unix permissions to control access, and doesn't log who made which particular push. And you also can't prevent people from faking who is listed in the commit field; anyone can put any value in there that they want.
来源：https://stackoverflow.com/questions/13502694/git-accountability