Setting up a simple git working environment

To get a feeling of git let's setup an oldschool central-repository schema. This is not a best approach to working with Git, but it is quite a viable one, pretty scalable in terms of team size and very easy to migrate from Svn.

To do this, we'll have to create a shared repository that everybody is going to work with (i.e. push local changes to it and pull changes of other project members) and a local repository that we are going to work with. Git supports several sharing protocols and in case you work in Windows-only environment the simplest one of them is just sharing via windows fileshare. So the idea is just to create "empty" repository, upload it to server and we are ready to go. No soft is needed to install on server side because git natively supports cloning\fetching\pushing over fileshare.

Client side is a bit more complicated to get started with. First of all you'll have to install 'msysgit'. This package contains command-line git toolchain and a minimalistic graphical client -- the Git GUI. Many hardcore programmers use command-line tools only and can't even imagine themselves working with any GUI. And even worse, I have a feeling that Git developers are also quite hardcore and do not even think about GUI. That means all available GUI are quite "third-party" and in general are adding to git problems their own bugs, specifics etc.

I would say that standard Git GUI tends to be unusable for groups of at least two people:

• the interface is not user-friendly at all, you have to know much about how things are working in git and so on;
• ofcourse, it is a bit outdated: for example it does not support stash;
• it has terrible localization that is switched on by default, so if are using localized version of Windows chances that you get it translated in such a way you'll never know what things actually mean;
• it is written in Tcl\Tk; many programmers nowadays haven't even heard about this language; plus the code is quite obfuscated so that you won't have great time adding your custom menus.

To fight with default localization I've used a simple hack that forces using english localization instead of default one. Create a batch file with following contents:

@set LANG=en

start /D "C:\Program Files\Git\bin" wish.exe "C:\Program Files\Git\libexec\git-core\git-gui"

and then create a link to this batch file on your desktop so that you could now run git client in one click (you can hack even more: if you duplicate pre-installed git desktop shortcut and then edit its properties to point to our newly created batch file, then you'll have the chance to enjoy Git icon instead of default icon for shortcuts to batch files).

Alternatively, you can use Git Cola client, but it is written in Python\Qt and is quite slow on most of operations if your repository contains at least 100 files. You woun't be able so read Git slogan "Git is a fast version control system" without tears while using this client.

You can use command line toolset and it is in fact a good solution for programmers but is totally unacceptable for artists, animators, designers etc.

I'm currently using a proprietary client (SmartGit) which is in general also rather bad, but I believe it is the best client out of all now available. It is written in Java and works on all major operating systems (I've tested on Windows, Mac Snow Leopard and Fedora Linux). It is casual enough for design people to kind of understand how to work with it without big issues (well, it's not totally true -- I'll later describe the problem with pull+discard).

So we've decided with tech: serving git with Windows fileshare and working using a graphical client (SmartGit in my case). Now let's create a new repository. It is noteworthy to say that there are two types of repositories in Git: bare and regular ones. Bare repository is just a database of whole development history with all commits, merges and so on. Regular repository is basically a bare repository plus a working copy (i.e. all the files on disc synchronized to so some commit\date\time).

For our shared repository we want to create a bare repository because having a working copy on server side makes no sense (plus regular repository will reject incoming commits when it is in the same branch you are pushing -- to prevent overwriting history and loosing data).

The easiest way to create bare repository is to use command-line. Create a temp directory, remember a path to this directory, open Git Bash and navigate to your temp directory (do you remember that Windows path like C:\Temp\git-shared will transform into /c/Temp/git-shared when using Git Bash? -- navigate using cd and ls commands). Use this command to create bare repository:

git init --bare

You'll have this output if all ok:

Initialized empty Git repository in d:/xxx/git-shared/

And temp directory will contain something like this:

hooks\
info\
objects\
refs\
config
description
HEAD


You can read much about what those files and directories mean in Git Book. We'll just copy all those files to central server so that it becomes shared to all other woking places via Windows fileshare.

Thats all about server side. Let's start with client side. Following steps mostly depend on what GUI you select to work with, but all you have to do is just to clone shared repository to your local machine. After having done it, you'll end up with regular repository (this means you get not only the latest version like in svn, but also all development history for all files -- thats why you do not have to worry much about backing up git shared repository: your system becomes more stable with each new client as cloning or updating leads to receiving all development history).

You can now edit files in your working copy and push them to shared repository. This way of working with git scales well to many client per one shared repository (but I'll later discuss isues with this approach).

This is all about setting up basic working environment, next post will be about everyday actions: fetch, merge, rebase, branch and switch. Stay tuned.