Information Technology Reference
In-Depth Information
This time the push is rejected even if it is a fast-forward. That is because Peter has
only R rights to the branch c .
How It Works
The best solution to host git repositories for the private projects of your team is to use
SSH with git account and public keys, as shown in Recipe 11-5. The problem with this
approach is that every user whose public key is appended to git user's author-
ized_keys file has full read/write access with forced pushes for every repository
stored in the git user's account. In other words every user who is successfully authen-
ticated by SSH to access that git account, gains full access to every git account. The
only restriction that you can enforce using built-in git features is to disable shell access
as we did in Recipe 11-5 with changing git user's shell to git-shell.
Gitolite is a tool to circumvent these shortcomings. It is very simple to install and to
work with.
Hint The complete gitolite documentation is available at ht-
tp://gitolite.com/gitolite/master-toc.html .
To start using gitolite you need a host serving git repositories over ssh using a git ac-
count. The git account cannot be restricted with git-shell. It needs an ordinary ssh shell.
The access to the shell of a git account will be restricted by gitolite itself. Thus, the first
account we need is git .
The second account we will use is the administrator who sets the privileges. He cre-
ates new repositories, removes repositories that are not used anymore, adds new users,
removes stale users, and defines appropriate rights for every user to every repository.
We will use the vagrant account in this role.
To fake the work by an ordinary user we will need another account. It will be named
peter .
Summarizing, in this recipe we work with three accounts:
git —this is the account used for ssh access
vagrant —he is the administrator, who assigns access rights
peter —he is ordinary developer who works in one of the repositories
Search WWH ::




Custom Search