Git DVCS – Getting started

Git is categorized as DVCS (Distributed Version Control System), because is not dependant on a central server. So the academic way for working with Git is pushing/pulling data from/to each developer repository. This works in small teams or in a highly distributed development (open source projects that people are working around the world), but in mid-size teams or business companies, that require a central repository because of infrastructure/workflow process like Continuous Integration System, QA Checks before delivering, Environment Backups, External Manual Audits… seem that a traditional SCM should be desired. But this claim is far from reality, Git is still your VCS; how about creating a theoretical central repository? I say theoretical because in Git there is no central repository at a technical level. This repository will act as central because of convention. I call, and in many other posts also call this repository origin.

A Git remote repository is a repository without working directory. Only composed by  .git project directory and nothing else.

Nvie has created a nice schema of this topology:

$ ssh <username>@<servername>

Now all structure is created and ready to be transferred. Case that initial project was started on developer computer you should copy this directory (using scp for example) to origin.

Then execute next command:

This command will add propertly group read/write permissions.

And now it is time to clone created repository to developer computer, I assume that developer has already an account in server (for connecting using ssh). So go to developer computer (or open another terminal) and type next command:

If user has read permissions to my_project.git directory, repository will be downloaded to local computer. Write permissions are required for checking in changes.

And now I suppose you are thinking that it was so easy creating a remote repository, but now another problem arises. If your company is small you can manually create a new user into your server for each developer, it should be easy to manage, but if your company is bigger, then management of all users is hard. You must create an account for each one, and more important, they will have access to server shell using ssh (not only for uploading code) or ftp, …, and this fact implies a problem with security, you should take care of what a user can do and what cannot do in his shell.

So arrived at this point, one can setup accounts for everyone, which is straightforward but can be cumbersome. Another way is using an LDAP or any other centralized system, but this is alien topic for this post.

A second method is to create an account called “git” on the server, and ask every user who will have  access, to send its SSH public key, and add that key to the .ssh/authorized_keys file of “git” user. I am sure that this approach sounds you familiar (github way?). So let’s explain this way:

First of all each user should send you its public key, (they can find in .ssh directory *.pub file), or simply create new, using ssh-keygen command. See this tutorial for learning how to generate both keys http://github.com/guides/providing-your-ssh-key.

Setting up Git server with user public keys:

First step is create a git user with .ssh directory.

#from server
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh

Next step is create authorized_keys file where all public keys will be stored:

For example:

#from server
$ cat id_dsa.user1.pub >> ~/.ssh/authorized_keys
$ cat id_dsa.user2.pub >> ~/.ssh/authorized_keys

And now each developer, with public key published in authorized_keys and private key in his own .ssh directory, has access to repository. Let’s try, open another terminal (would be developer machine in real scenario) and try to clone existing repo from server:

#from developer computer
$ git clone git@<servername>:<directories>/my_project.git

After repository is cloned to developer computer, modifications can be made and pushed them.

And now you can say, “Ok, I don’t have to create one account for each developer but I am still having a problem with security“, each developer still has access to shell. Yes it is true, but you can easily restrict the “git” user to only doing Git activities with a limited shell called git-shell. Next step is specifying git-shell instead of bash for Git user, in /etc/passwd.

$ sudo vim /etc/passwd

and change

git:x:1000:1000::/home/git:/bin/sh

to

git:x:1000:1000::/home/git:/usr/bin/git-shell

Now your server is secured, only Git operations are allowed using “git” account with users that have sent their SSH public key.

You have your central remote repository configured and ready to be used; at this point you may consider install Git tools like gitweb, gitosis or gitolite, but in this post are off topic.

I hope you have found this post useful.