Set up git and gitosis on Ubuntu

Introduction

Gitosis is used to help centrally manage git repositories. Gitosis will allow:

  • SSH access to repositories (with the help of openssh-server).
  • User management without the need to add server shell accounts for each person accessing repositories.
  • While gitosis manages user repository access, gitosis is accessed through a single shell account (its use is limited to a specific gitosis command in ssh config).

Central Repository Server

Install gitosis (apt-get should install all dependencies):

paul@server$ sudo apt-get install gitosis

As the first administrator of the gitosis installation, grant access to gitosys for yourself by passing in your SSH public key (the one you currently use to securely access the server via ssh can be used, but better practice is to use one specially created for gitosis access – see section below on creating and managing ssh keys) to the gitosis-init command:

paul@server$ sudo -H -u gitosis gitosis-init < ~/.ssh/id_rsa.pub

After executing the above command you should notice that the gitosis authorized_keys file (~gitosis/.ssh/authorized_keys) has been populated with your public key. gitosis will add new entries to this file when new users are granted access to the gitosis system.

Cloning the gitosis-admin Project

You should now be able to clone the gitosis admin repository to your workstation:

paul@workstation$ git clone gitosis@server:gitosis-admin.git

Be sure that your workstation is correctly configured to use the ssh private key counterpart to the public key that you used when initialising gitosis (see above).

As the admin you can now manage gitosis system access by adding and removing user public keys in the keydir directory of the gitosis admin project directory (shown cloned above as gitosis-admin). Projects and user access to those projects is managed by editing the gitosis.conf file found in the gitosis admin project directory.

SSH Key Management

This isn’t a tutorial on ssh; just a little assistance with commonly required ssh config when adding access to new gitosis users on your system.

Each user should should create a public/private key pair for exclusive use in accessing your gitosis service. The key pair can be created using ssh-keygen as follows:

$ ssh-keygen -t rsa

When ssh-keygen requests a filename, provide something that will help you, the workstation user, associate the key file names with their intended use, e.g. gitosis@server-name.id_rsa

In your workstation’s ~/.ssh/config you should instruct ssh to use those keys against your server for the gitosis user:

Host gitosis.server-name.com
User gitosis
Hostname server-name.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitosis@server-name.id_rsa

The ssh public key file (the one ending .pub) can then be added to the keydir directory of the gitosis admin project. You may wish to rename the public key files to something like paul@workstation when copying them into the keydir directory.

Adding New Projects

As an administrator of a gitosis system, it is possible to add new projects. Within the gitosis-admin project, add a new project entry, adding the names of the public key files (less the .pub extension) for the members you wish to grant access:

[group project-team]
writable = new_project
members = paul@workstation fred@anotherworkstation
 
[group gitosis-admin]
...

Commit and push the changes to the gitosis server:

 $ git commit -a -m "Added new_project as a new project."
 $ git push

It should now be possible to push the project files up to your gitosis server:

$ mkdir myproject
$ cd myproject
$ :> hello.py
$ git init
$ git add .
$ git commit -a -m "Initial commit."
$ remote add origin gitosis@server.com:new_project.git
$ git push origin master

Gitosis Username and Project Directory

Warning: you probably shouldn’t do this… The Apt scripts will assume the original username and home directory, so the following changes may break future Apt updates.

The Ubuntu Apt system creates the user gitosis to access the server. If a different username and/or home directory are required then it’s necessary to apply changes to the gitosis user account. To change the home directory (from the default /srv/gitosis to /home/git):

 paul@server$ sudo usermod --home /home/git gitosis

To change the username used to access gitosis (from gitosis to git):

paul@server$ sudo usermod --login git gitosis

 

Subversion Branching Guide

A Quick Guide On Subversion Branching

This article summarises how to create and manage branching in a Subversion repository. For thorough coverage of the subject see the Red Bean Subversion book for your release of Subversion.

Creating a New Branch

A new branch is created in a repository using the svn copy command:

$ svn copy http://svn.example.com/path/to/trunk \
    http://svn.example.com/path/to/branches/branch-name

Working on a Branch

If you have a working copy checked out from trunk (usually the main line of development) and have local changes that should be committed to the newly created branch, then update your local working copy so that you have the same updates from trunk as are currently on the branch.

You may now use the svn switch command to change your local working copy to work with your new branch.

$ cd my/local/working/copy/
$ svn update
updated to revision 123.
$ svn switch http://svn.example.com/path/to/branches/branch-name

Alternatively, you can perform a check-out directly from a branch:

$ svn checkout http://svn.example.com/path/to/branches/branch-name .
 $ cd branch-name

You can now commit any changes that are in your local working copy and they will be applied to the branch and not the trunk.

$ svn commit -m "Some changes for my new branch."

Merging Trunk Changes into the Branch

You should keep your branch up-to-date with changes that are committed onto the trunk. This minimises the potential for conflicts when the time comes to merge your branch back into the trunk. You use the svn merge command to pull trunk changes into your local working copy of the branch. If any conflicts are found, then you should resolve them before committing the effect of the merge and any conflict resolution changes:

$ svn update
 updated to revision 124
 $ svn merge http://svn.example.com/path/to/trunk
 ...
 $ svn commit -m "Bringing branch up-to-date with changes to trunk."

Reintegrating Branch Changes into Trunk

Before merging your branch back into the trunk, ensure it is up-to-date with any changes that have been applied on the trunk – see the section above for details. You can then apply the changes on your branch to the trunk using the svn merge command and the reintegrate flag. First get a clean working copy of the latest version of the trunk:

$ svn checkout http://svn.example.com/path/to/trunk trunk ...
$ cd trunk
$ svn merge --reintegrate \
http://svn.example.com/path/to/branches/branch-name
--- Merging differences between repository URLs into '.':
...

As with merging trunk changes into a branch, you should now resolve any conflicts that may have arisen merging the branch into your local working copy of the trunk. Once you’ve done that you can commit the effect of the merge into the trunk:

$ svn commit -m "Merge my branch into trunk."

You’re done!

After merging a branch into the trunk using the –reintegrate flag the branch can no longer be used (at least using Subversion version 1.5). You could tidy things up on your repository’s branches folder by deleting the old branch, safe in the knowledge that it is still retained by Subversion in it’s database at a specific revision number. All that is required is to find that revision number (say, using the svn log command) and use the svn copy command to copy the revision to a repository branch location.