As a software developer one of the tools of the trade we need is a revision control system. This system tracks changes to the source code files and other documents related to individual projects that I am working on. Recently I have been using Git to track my projects.
Git is an open source project that was originally designed to deliver software patches and updates for Linux distributions. It has evolved to the tool I use today. Git by itself only does document management. It borrows off other technologies to provide a complete solution.
To install git, I recommend installing through MacPorts (http://www.macports.org/). MacPorts provides a series of Unix utilities ported to the Mac. It is well supported, and if you develop Firefox plug-ins like I do at the moment, MacPorts is required, so this is my recommended method to install Git.
Macports can be installed by either compiling the source code directly with Xcode, or just use the DMG installer built for the version of OSX that you have on your Mac. Once you have Macports installed you need to install the tools you will need.
> sudo port install git-core +universal
this will install the latest version of Git on your mac plus any dependent utilities. If you are running 10.7 then you will want to include the “+universal” to your port install command. This installs support for 32 and 64 bit versions of the port commands you are installing. You will need to install Git on each machine you use for development including the gitolite server machine.
SSH key generation
Before installation you will need to create a set of keys that are used to identify users. At this point you need to decide how you are going to proceed with the security of your development projects. You can either generate one key per user, then copy that key to each development machine that each developer will use, or assign a key to each machine/user combination.
- One key per user is easier to maintain, but this could lead to security leaks if those keys get lost or copied to machines outside of the project boundaries. I don’t particularly like that aspect of this strategy. you can’t identify or control where the user logged in from.
- One key per machine/User might be a better option because then you not only control the user access, but also where that user can log in from. I think this method offers a better tracking of when and where a user logs in from.
> ssh-keygen -b2048
follow the instructions to create your keys. The default location for the keys will be in a folder “.ssh” in your home folder. Inside that folder there should be 2 files. The files are typically named id_rsa and id_rsa.pub. The .pub file is what we are interested in. this is your public key. each user will have a unique key, gather those keys up and name them to identify each user. I use their login name to name the public key.
Installing gitolite is straight forward. Gitolite uses a User account to act as a proxy to the assign and manage the rights to the Git repositories under its control. Gitolite uses a Git repo to manage the administration of all the repositories with a very easy to use configuration file.
Before installing gitolite, you need to create a standard user account where gitolite will be installed. I created a user “Git” and this is what will be referenced for the rest of this article.
I grabbed the instructions from the Gitolite home page (http://sitaramc.github.com/gitolite/install.html) and used the non-root method for installation
> git clone git://github.com/sitaramc/gitolite > gitolite/src/gl-system-install # defaults to being the same as: # gitolite/src/gl-system-install $HOME/bin $HOME/share/gitolite/conf $HOME/share/gitolite/hooks # to upgrade gitolite, repeat the above commands. Make sure you use the # same arguments for the last command each time.
At this point you will have to modify the Bash environment to include the path to the Gitolite bin folder in the Git users home folder. Once that is done you can proceed with the next step.
To finish the installation of gitolite, you need to create the admin repo and assign the administrator.
> gl-setup admin.pub
Now your are done with the server-side changes. On your workstation we can finish the rest of the configuration. To administer gitolite managed repositories, you need to clone the admin repo and add users and repositories.
> git clone git@server:gitolite-admin
This will clone the gitolite admin repo to your local machine in a folder called gitolite-admin. This folder will be created in a sub-folder off your current directory. In there you will have two sub folders
- conf – contains the repository configurations
- keydir – the folder where you place all the users keys.
Gather up all the keys that were generated for each of the users for the repos, and place them into the keydir folder
Inside the conf folder there is a file called gitolite.conf.
repo gitolite-admin RW+ = admin repo project1 RW+ = dev1 RW+ = dev2
In this file add your repositories. Repositories can be added by adding them to the config file and then committing the results. This has the effect to create any repository that doesn’t exist. Now you are done with the installation once you have pushed these configuration changes to the server.
> git commit -a -m"initialized gitolite" > git push origin
The first command commits the changes to the gitolite-admin repository that you cloned to your workstation. The next step publishes those changes to the server which instructs gitolite to configure the repositories with the updated access rights, and to create any new repositories that have been added. Any new repositories created will be placed inside the configured repositories location or off the repositories folder placed in the Git users home folder on the server. You users should not access these repos directly. Now all your users can access their projects by cloning them from gitolite using the git clone command.
>git clone git@server:project1
that’s it your done… Configuration and maintenance is fairly easy. That will be covered later.