Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Git Tip of the Week: Setting up a shared repository

2011, git, gtotw, tip

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.