Git Rulez

Every project developed by more than one person needs a versioning control system. And, in my opinion, it's a good idea to use a VCS for all non-trivial projects.

According to wikipedia:

Revision control, also known as version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information.

In my developer life I've used three VCS:

• CVS (Concurrent Version System)
• Borland StarTeam
• Git

And from the title of this post you should have understood that I believe the last is the best. It has a lot of features that help to manage big projects ran by hundreds of developers, since it was created by Linus Torvalds with the purpose to maintain the sources of the Linux kernel.

How It Works

Git is a distributed VCS, this means that when you clone a repository, you have the whole history and the all the branch tree in your PC. You can do your work offline on the repository and when you are done, push it to the remote repository. And it's not said that the remote repository you are pushing to is the main repository. It can be the repo of another developer that is working with you on a specific feature. In this way two or more persons can do their work without impacting the whole dev team.

Another difference with other VCS, is that Git does not track files but changes, even in different files. How many times your new features or bug fixes are made in a single file? Usually, adding a new feature means change several files; when you commit them, they remain together so it's easier to identify all the files changed and, if needed, revert the modification with just one command.

Moreover, this behavior lets you view an history of all the commits and lets you easily go in a well-known repository state even without having set a tag.

Branching

A Git book I've read says that books explaining other VCS talks of branching in the latest chapters. But in every Git book, you'll find branches treated within the first three or four chapters. Why this difference?

Simply because branching is a very powerful feature and in Git the creation a new branch is a very cheap operation. An with "cheap" I mean that there is no data duplication or hidden overhead. Simply two commits will have the same ancestor.

When you work with branches (in whatever VCS) a typical need is to do the same modification (for example an urgent bug fix) on different branches. Git provides the cherry-pick command to do exactly this: to replay a commit (i.e. the changes made to one or more files) in another branch.

Conclusions

This posts is only an overview of Git but I hope it's enough to make you understand how powerful this tool is. In the future I plan to write some posts about useful but almost unknown Git functions.