In the middle of last night, I decided to finally get my local git repository back on my server before going to bed. I was too lazy to read any detailed documentation, so I just googled a few howtos. None of them was entirely complete, so the following is culled from a small number of them.
I had a server running Ubuntu 12.04 and a client (running the same version, but any Linux distribution should do). The client already had git installed, with a local repository I’d been using for a while. I wanted to get a git server running on the server and push the local repository there, so that when everything was done, the local repository would just be a clone of the main one on the server.
I’d read about gitosis repeatedly, but as it turned out, Ubuntu had dropped support for that in favour of gitolite, so that’s what I ended up putting on the server.
All the necessary packages are in Ubuntu’s standard repositories:
sudo apt-get install git gitolite
We’ll be handling gitolite via a separate user, so we have to create it (sans password, so no direct logins possible):
sudo adduser \ --system \ --shell /bin/bash \ --gecos 'git version control' \ --group \ --disabled-password \ --home /home/git \ git
Access to gitolite will be authenticated via SSH keys. If the user we’re installing gitolite with doesn’t yet have a SSH key pair, we can create one:
ssh-keygen -t rsa
We’ll need the public key for the git installation. As the git user doesn’t have access to our .ssh directory, we copy the key file to the temp directory:
cp ~/.ssh/id_rsa.pub /tmp/local.pub
Now we can login as the git user and setup gitolite:
sudo su git echo "PATH=$HOME/bin:$PATH" > ~/.bashrc gl-setup /tmp/local.pub exit
gl-setup will open the gitolite config file in the editor, but we can just accept the defaults by saving and closing.
Back in our regular user account, we can now clone the gitolite-admin repository, which is used to change the repository configuration:
git clone git@localhost:gitolite-admin.git
We’ll be using gitolite-admin to add the login key for our remote user and to create a new repository.
First, let’s allow the remote user (on the client system) to access gitolite. We need the user’s public key file (if the user doesn’t yet have a key pair, see above).
gitolite expects all key file names to follow the pattern <username>.pub. They can, however, be nested in sub directories. Since the same user may have different keys on different machines, we use a separate directory for each client to store the key files:
mkdir gitolite-admin/keydir/myclient cp my_uploaded_id_rsa.pub gitolite-admin/keydir/myclient/myusername.pub
We can now add a new repository and give our user access to it by editing gitolite-admin/conf/gitolite.conf, like so:
repo gitolite-admin RW+ = local repo testing RW+ = @all repo mynewrepo RW+ = myusername
The first two repositories were already configured. I added “mynewrepo” and gave “myusername” full access to it. Multiple users can be specified by multiple permission lines for a repository. The “@all” keyword can be used to grant permissions to all users who have access to gitolite.
To activate these changes, we simply have to commit and push gitolite-admin:
git add -A git commit -m 'New user keys and new repository.' git push origin master
The new, empty repository should now be available and you should be able to do this on the client system:
git clone git@myserver:mynewrepo.git
Note that gitolite repositories are always access as the “git” user. gitolite will recognise your actual user via your SSH key and use the appropriate permissions.
Pushing the existing repository to the server
The only thing missing now is making the newly setup server the origin of the git repository we already have. This is simple, just do this from within the local repository’s directory:
git remote rm origin git remote add origin git@myserver:mynewrepo.git git push origin master