As the first of a new series of Git Tips, I'm posting a git tip per week. If you don't subscribe to my blog then these are available as a separate feed which you can subscribe to.
Shared Git repositories
If you have a team working on a Git repository, then at some point you want to allow them to merge their changes together. This is typically done with a centralised server that all developers have access to (there are more flexible models, which we'll ignore for now).
To set up a shared repository, you typically want to log in via SSH. The easiest way of achieving this is via public key authentication, which I have described before. Once that is set up (or you decide to use password based authentication), a shared repository is as simple as running:
$ ssh hostname git init --shared --bare /path/to/repo.git
You'll now be able to clone this using:
$ git clone ssh://hostname/path/to/repo.git
Permissions
The repository is set up with the standard umask
permissions. If your developers all default to being in the same group, then they should all have the same access rights. If not, you may need to change the group of the repository to limit the access to the appropriate group of users:
$ ssh hostname chgrp -R devgroup /path/to/repo.git $ ssh hostname chmod -R g+wX,o= /path/to/repo.git $ ssh hostname find /path/to/repo.git -type d -exec chmod g+s '{}' ';'
Since the chgrp
command wipes out the shared group bit, we have to put it back again with the latter find
. We could have done the chmod
by specifying git init --bare --shared=660
; but we'd still have to repair the group bit if we changed the group to something else.
Come back next week for another instalment in the Git Tip of the Week series.