Setting Up A Git Repository

All the version control systems I have worked with so far like CVS, VSS and Team Foundation Server are centralized version control systems. Git, however, is a distributed version control system. Clients don’t just checkout the latest snapshot from the server, but they mirror the entire repository.

So, when I decided to setup my own version control system for personal use, I decided to give Git a try.

Git can be installed on any computer and you have a version control system right away. However, I also wanted a remote repository on my main file server (maybe bias from working with centralized version control systems for many years!)

To achieve this, Git has to be installed on the main file server (remote repository) as well as on the local computer (local repository). The good part about this setup is that the local computer does not require to be connected to the server all the time (which is usually the case with centralized version control systems). It needs to be connected only when the changes has to be pushed back to the main server (remote repository). This is different from other centralized version control systems where the clients has to be connected to do any operation like compare previous versions / branch / check-in / check-out etc.

Installing Git on the remote server

Let’s first install Git on the remote server. I use a Synology disk station that runs BusyBee Linux as my main file server.

Instead of ipkg, use whatever package manager is available on your distribution. If you are using Synology and do not have ipkg package manager, you can install ipkg by following my earlier post Bootstrapping Synology DiskStation – Unleash The Power.

Initiate a bare repository on the remote server

Now that Git is installed, initiate a bare repository. There are 2 types of repositories in Git – bare and working. Bare repository is one without a working directory. For the remote, initiate a bare repository.

Install Git on the local computer

I use a Windows 7 machine as my local. Installed the Git core for Windows from msysgit. You can also find the download for Windows from here.

This installs the core, a bash and a minimal GUI.

Even though this is enough for most of the Git operations, I prefer to use the Git Extensions locally. Git Extensions has windows explorer integration and also integrates with Visual Studio.

Initiate a new repository from Git Extensions. If you already have a source code folder, you can choose that to create a new repository and convert the existing folder as a working folder. Choose ‘Personal repository’ as we want a working folder on the local.

After a few commits and branching and merging, the local repository looks like the below. It gives a good visual interpretation of what’s going on.

Connecting the local repository with the remote

Being distributed, one local repository can be linked to one or many remote repositories. In Git Extensions, go to Menu > Remote > Manage remote repositories > New

The recommended method of connecting to a remote is to use a SSH connection with public / private key authentication, without getting prompted for the password.

However, I chose to use another method. My remote is on a file server that I have access to and can be accessed from Windows machines on the local network. I  created a samba share to the remote repository folder, and created a network drive mapping from my windows machine. (P: as shown in the below screenshot, points to the remote repository created above in /volume1/git ). This is not a recommended method if there are many users, but works fine in my case.

Push changes to the remote

When the changes are ready to be pushed to the remote, click on the Push button. There is a also Pull button to pull any changes other users might have done.

When the changes are pushed to the remote, all the commits, branches, merges and other operations done locally are pushed to the remote repository.

If another user has committed to the remote during the time you were making changes locally, Git will not let you push to the remote directly. You will need to pull the changes from the remote, merge those changes into your own repository, resolve any conflicts and then push the changes to the remote. This built-in mechanism protects one user’s changes to be overwritten by another user accidentally.

GitList – A beautiful web interface for the repositories

I tried a few web interfaces for viewing my remote repositories, but GitList stood out from the rest by it’s minimalistic approach.

It was a pretty easy installation on a PHP / Apache The below installation instructions are from the GitList author.

• Download GitList from gitlist.org and decompress to your /var/www/gitlistfolder, or anywhere else you want to place GitList.
• Rename the config.ini-example file to config.ini.
• Open up the config.iniand configure your installation. You’ll have to provide where your repositories are located and the base GitList URL (in our case, http://localhost/gitlist).
• Create the cache folder and give read/write permissions to your web server user:

The options in the config.ini are simple at best.

See few screenshots below:

 

References

An excellent book on all things Git:
http://git-scm.com/book

Git downloads:
http://git-scm.com/downloads

List of GUI clients:
http://git-scm.com/downloads/guis

GitList – web interface:
https://github.com/klaussilveira/gitlist
http://gitlist.org/