GIT

I want to share with you some thoughts on GIT because I think that was a right invention to the right time and place.

(This article should be finished half year ago right after i wrote [intlink id="subversion-on-debian-linux" type="post"]about svn server installation[/intlink], but unfortunatelly i didn't find any time to finish it untill 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 moderatelly 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 powerful source control system and many many people and companies started using it. I think it's the most used version control system.

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 and [intlink id="subversion-on-debian-linux" type="post"] easy installation and configuration[/intlink].

But that's all what i like... There is no more practical advantages over CVS and moreover there are even 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 them commits '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, performance gain very fast on importance ;)

Folder movement is a nightmare. With the subversion you have to know what you do when you start move around your folders. ;)

Ugly .svn folders in the folder tree of your project. O course cvs had them too. But do we really need them? Sometimes i just wanna to copy my project tree without that stuff.

There are also more properties and configuration possibilities for git. But for normal usage you will never need them. If you think different see git config manual.

Normally you will be ready with git installation now.

Usage (Remote repositories)

First you should think about your branching model. Start by nvie model. It looks a bit complicated, but it covers nearly every aspect in big project work. In an agile team such an approach is very easy maintained by git. See also related Stackoverflow discussion.

There is a lot of documentation on git usage on the internet so it makes not much sense to cover everything here again. But if you was interested in installing git, maybe you plan to maintain new reposity, so let's look at them.

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

Then you can clone this (remote) repository to the local one

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

Continue to work with local repository, add, remove, and commit files to local one. If you decide to propagate your changes, say at the end of a day, to the central 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 which 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: