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 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:






An excellent book on all things Git:

Git downloads:

List of GUI clients:

GitList – web interface:

Bootstrapping Synology DiskStation – Unleash The Power

Synology disk station comes locked and does not allow any modifications as it comes out of the factory, however there is a healthy community supporting the boot strapped operations. Bootstrapping is required to install additional packages on the server, other than the default packaged ones, which I should say are not any less.

Let’s start!

1. Bootstrapping program is dependent on the type of CPU on your disk station. See here to find your CPU Type.

2. Make sure the disk station has the login over SSH enabled.


3. Login to your disk station over SSH (I use putty) as root. Enter your admin password when prompted.

4. Change to the @tmp directory.

5. Download the bootstrap file for your CPU to the @tmp directory using wget. The example below is for the CPU type ‘Marvel Kirkwood mv6281 ARM processor’. Please find out the bootstrap file for each CPU type from the page Overview on modifying Synology server.

7. Change the bootstrap file permissions, so that it’s executable.

8. Execute the bootstrap file

9. Now, comment out the PATH and EXPORT in the .profile file and save.

10. Reboot the disk station.

11. Login to the disk station using SSH as root.

12. Update ipkg list. ipkg is the default package manager.

13. Install coreutils

14. Check what other packages are available to install

15. Check what packages are already installed through ipkg

At this point, you have all the software installed to add other packages and make any changes to configure the disk station as required.

Have Fun!

Install SCP

DSM 4.0 disk stations do not have SCP installed by default. I find SCP to be the easiest for copying files to the disk station. Moreover, if you are setting up public/private key authentication for password free authentication, the arrangement works very well with SCP, allowing, say a backup program, access the disk station without having to know it’s password.

1. On the disk station, change to @tmp directory

2. Get the OpenSSH package

3. Un-package

4. Inflate the tar file

5. Copy the binary to the bin

SCP is now installed, give it a spin!