Let's start from the beginning!

Goodbye Cvs Hello Git

Prologue

So I finally started writing my own blog! How exciting!

I was thinking what should be my first post about?! I can write on some technical problem and its solution, but that would probably be the subject of most of my posts. My first post should be something a bit different.

The most important tool that every team of developers should use is a source code management system. It enables the team to work together on the same files of code, to keep track of code changes, and be able to get one final version of all the code together, which will be compiled to the final product release. As my team recently went through a change, I think this is a good subject to begin with.

Why not Cvs?

Until a few months ago we were using Cvs. Cvs in a centralized version control system, keeping its repository on one server, and all of the developers are checking files in and out of that repository. I always used to find working with Cvs frustrating.
Cvs is generally slow, depending also on the quality of the server on which it is installed. Whenever I had to get the latest version from the server was always a good time to go and make myself some coffee...
We also used to have some strange problems from time to time. Sometimes code that we were thinking that was checked in was not really checked in, sometimes you knew that there is a newer version on the server, but the system insisted you had the latest version.
But the most significant disadvantage of Cvs is the lack of atomic check in. What does it mean? Let's say I fixed a bug, and I made changes to 3 different files. I would like to check them all at once, with a comment "bug number X was fixed". Then I will always be able to track this bug, and if I am asked to fix this bug for a hot fix or a minor version release I will be able to easily find all the relevant changes related to this bug. So using Cvs we used to answer such requests with "No", "We can't", "Impossible".

Why I think Git is better

So lately we started using Git, and it is so much fun working with it, that I even started using it at home for my weekend projects!
Git is a distributed version control system, which means that there can be more than just one repository. We have one central repository and a repository for each developer. At home I have a repository on my own computer and a remote repository at Bitbucket.org. It is good even if you have just one repository, then you do not have backup, but you still keep history of your code and can go back to each previous version that you like.
In my opinion, the advantages of using Git over Cvs are:
1. It does not mark files as read only, so you can just go ahead and edit them with no need for check out, which takes a few moments. It is much more fun working that way.
2. You are not dependent on the central repository when you code, so you can keep working and commit files even when the central repository or the network are down.
3. It handles much better deletion or renaming of files.
4. It handles conflicts much better.
5. It is much faster.
6. It has the atomic commit.
7. It also has a cherry pick option. This option allows you to select an atomic commit and apply it on another branch! So if you solved a bug for the next release, and you now want to create a hot fix for the previous release, it can be done very easily.
8. It is much easier to create new branches. In fact, many Git users recommend branching as much as you can.You can create a branch for each feature and merge it to the other branch when it is done.
9. I simply feel that it is more reliable, easier to work with and more fun.

Changing your perception

As far as I understood, Git does not manage files, but instead it manages change sets (each atomic commit is a change set), and by doing that it gets some of its advantages.
So far what we found annoying is the way of synchronizing between our own repository and the remote (central) repository. This is done by Pull (get code from the central repository) and Push (put code to the central repository). You must pull before you can push and you should not have any changes in your working directory when pulling. For anyone who used to work with Cvs this may be a little annoying.

However, when moving from Cvs to Git you should probably change your perception. As you have your own repository you may not sync with the remote repository as often as before. You can also create more branches and then pulling and pushing becomes easier as it is just for a smaller branch having less changes.
On the other hand, our CI (Continuous Integration) machine is based on the remote repository, so frequently pushing to the remote repository is good from that point of view.
Eventually, I guess it's all about finding the right balance , choosing what is best for you, and constantly looking for ways to improve.

Some installation and usage tips

Git comes from the Linux world and is typically used with a command prompt. For us as .Net developers this may be uncomfortable, so we use Git Extensions which has all the every day functionality you need. We already had the chance to use some more advanced commands using the command prompt, but these cases are rare.

The remote (central) repository is installed on a server to which access is very limited, in order to avoid damage to that repository, whether it is by accident or by intention. The access to the remote repository is done over HTTP using WebGit.NET, but there are also other such projects available, there is some more information about them here: http://stackoverflow.com/questions/438163/whats-the-best-web-interface-for-git-repositories.