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 about svn server installation, but unfortunatelly i didn’t find any time to finish it untill now.)
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 easy installation and configuration.
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.
- Not closed connection (don’t know if it is an server or eclipse plugin bug). Sometimes svn commits leave not closed connection. Eclipse hangs.
- SVN consumesa 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 much faster, flexible. So let install it!
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 18.104.22.168 $ 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 "email@example.com" $ 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 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:
# 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.