git: how best to set up the user model on "back-end server"

Question

I have a very specific question on the user model. (I'm guessing asking this question will betray my ignorance, but hey, I just want to know!)

I have a simple Ubuntu server that will hold our project repository from which about 6 guys will clone the project. Each has his own user account on this host. The project repository resides on the path /home/git/project-name.git. I could set up a group to corral these users and the git user.

When the developer users push to this remote repository, I don't want them doing it all as the same user (say user 'git' or something) since I want to know who has done what.

If I have everyone drop an id_rsa.pub.name key onto the path /home/git/.ssh/, then add themselves to */home/git/.ssh/authorized_keys* , I'm not going to find out who did what, right?

Therefore, do I grant full access to /home/git/project-name.git to each the group to which the developer user accounts belong on this host?

Any advice would be warmly welcomed.

Thanks, Russ

Answer 1

Rather than Gitosis, I would recommend Gitolite for fine-grained authorization coupled with ssh-based authentication.

Answer 2

The general practice is to have one account rather than having several ssh accounts for everyone wanting to push to a repo.

http://progit.org/book/ch4-4.html

http://blog.felipebalbi.com/2008/01/03/git-push-and-ssh-keys/

This doesn't remove you of the ability to know who committed what. The author/ committer is independent of the ssh user.

Answer 3

I recommend using something like Gitolite (download) for what you want, so you can chose who has access to what. You set up a "git" user that everyone uses for Git pushes. Git itself tracks who did what commit, so you shouldn't lose that.

Answer 4

Letting multiple users write to a repository does not mean that you will be able to determine “who has done what”.

It is true that the first (server-local) user to create a particular object (blob, tree, commit, annotated tag) will be the owner of the object’s loose object file (though any other user with write access could probably delete and rewrite the file), but ultimately those loose object files are ephemeral. The individual loose objects will eventually be packed and deleted (e.g. via git gc, either manually or automatically once enough loose objects have accumulated).

Git does neither authentication, nor authorization, thus is has no idea about the “user” that is doing a push¹. Since it has no concept of the active user, it can not provide a log of “who pushed/modified/deleted what”. If you need such an audit log, you will have to rely on whatever tool is actually doing the authentication. Unfortunately, many Git hosting tools focus on the distributed nature of Git so they tend not to offer much support for “centralized” features like an audit log. There are some exceptions, though:

• Gitolite keeps a log that might be usable as an audit log (the authentication is done by either the SSH server or the HTTP server, but Gitolite does the authorization).
• Gerrit seems to have some built-in restrictions that try to more strongly associate the committer (and author, depending on configuration) user information with the authenticated user accounts (see Forge Identity); while this is not an audit log, it might suffice if you consistently restrict the “forging” authority.

(There are probably other tools or services that have some logging/restriction features, too.)

See Also: Git Log History

¹ Git does keep track of an author and committer for each commit (tagger for each annotated tag), but their values are not restricted by Git. Anyone can change the effective author or committer by changing (or overriding) their user.email and user.name configuration variables or setting the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL environment variables while making a commit or tag.