I would like to share some thoughts on GIT because I think that was a right invention at the right time and place.

(This article should be finished half year ago, right after i wrote about svn server installation, but unfortunately i haven’t found any time to finish it until now.)

Motivation

My first version control system (VCS) was CVS and I used it with eclipse 2.0 for programming in java. I found CVS quite impressive and liked it a lot. It was also quite reliable and moderately fast. Then someone at the university told us to use SVN, because it has “plenty” of advantages. Somehow I found SVN not bad even if the eclipse svn plugin quality was never quite good. However, SVN matured and became a powerful source control system and many people and companies started using it. I think it’s the most used version control system today.

I like SVN for easy branching and tagging (with good eclipse plugin support), for global version numbers, for understanding “http://” (with Web-Dav) as well as for more comfortable managing tools, easy installation and configuration.

But that’s all what I like… There are no more practical advantages over CVS and moreover, there are unfortunately some disadvantages also in comparison to cvs.

  • SVN is slow and double slow over HTTP. It may not be critical if you do your changes on several files and they commit ’em. I’m doing so in my java project and it’s ok. But there could be also other scenarios e.g. if you deal with such “monsters” like magento, which consist of many files and SVN is very slow here.
  • Folder movement is a nightmare. With the subversion, you have to know what you do when you start moving around your folders. ;)
  • Ugly .svn folders in the folder tree of your project. Of course cvs had them too. But do we really need them? Sometimes I just wanna copy my project tree without that stuff.
  • Not closed connection (don’t know if it is a server or eclipse plugin bug). Sometimes svn commits leave not closed connection. Eclipse hangs. :(
  • SVN consumes a lot of space, more than cvs local and on the server.
  • You need to be online if you want to commit.

All of these disadvantages I mentioned above are fixed in GIT. Git is also much faster, flexible. So let install it!

Installation

We start with installing the git-core component from Linux (Debian in my case) public repositories.

apt-get update
apt-get install git-core

After executing of these commands, which takes only approx. 2 seconds. you have installed the git-core on your machine. So now you can test it by checking the version or common commands list

git --version
# Returns e.g.:  git version 1.5.6.5
$ git
Returns usage options

First good thing to do after a fresh git installation is to define some global properties:

git config --global user.name "Alexander Holbreich"
git config --global user.email "alexander@xxxxx.org"
git config --global color.status auto
git config --global color.branch auto

There are also more properties and configuration possibilities for git. But for normal usage you will seldom need them. Normally you will be ready with git installation now.

Usage (Remote repositories)

First, you should think about your branching model. You can start to understand what is possible with git in contras to SVN by checking nvie model. It covers nearly every aspect in big project work. Still this can be very easily maintained by git.

This model has become to be used as dogma! Be careful you don't need to have it complicated like this.

See also related Stackoverflow discussion.

There is a lot of good documentation on git usage on the internet, so it makes not much sense to cover everything here again. But if you were interested in installing git, maybe you plan to maintain new repository, so let’s look at that moment.

Small teams maybe would prefer to work with one central repository centralized workflow for it is a common approach we know from svn and cvs times. Below a bare repository is created as a central one:

git init --bare
# Creates a repository on a server that you would use as integration truth. So called "origin"

Then you can clone this (remote) repository to your local one on your local machine.

git clone git://originrepository.place/somedir/

Continue to work with local repository, git add, git remove, and git commit files to local one.  If you decide to propagate your changes, to the remote repository, use:

git push origin master

Cloned repositories know their origin repository automatically. “Origins”  have to be bare repository because they have no checked-out working trees. If you push to a repository that has a checked-out working tree (which is still allowed) the working tree will not be updated, and that may lead to unexpected results. To sum up, let your central repositories be created by git init --bare.

In git, it is possible to have several remote repositories for one local. You can add them like this:

#here http is used as example
git remote add somelib http://someremoteplace/lib/repo..

where “somelib” is the alias of repo. Next command shows known remote locations:

git remote -v # shows defined remote repositories aliases with URLs.

I hope this gives you a motivation to start using GIT. Hope also to see your questions or ideas in the comments.