Version control in Git - Part 1

Note: this post is over a year old, it's very likely completely outdated and should probably not be used as reference any more. You have been warned. :-)

Version control systems are evil. They hate me and are out to get me. I can't count the number of ways that I've been bitten by SourceSafe (safe.. ha! get it?), CVS, SVN and TFS.

Enter Git, my saviour. For now. I have literally worked with Git for three days, so I know very little and I can't claim that it will be any better than the rest of them, but it sure seems like a great system and I've seen very good reviews online.

Advantages

Working with Git, as opposed to other source control systems has some key advantages.

Git is great for experimental projects, where you want to give your developers the power to experiment wildly without any of their experiments getting into the source control system if they don't work out. Making a new branch in Git is easy, merging the branch back is quick and simple. Git just gets out of your way and does the hard work for you.
Of course you could still have merge conflicts sometimes, and they need to be resolved by hand, but at least you can trust the rest of the merge to go well (unlike the horrors I've seen in CVS and SVN).

One of the things that I really like is that Git only creates one folder in your source code file structure and not one folder for each directory (like CVS/SVN). Git also does not require all your files to be read-only, like in TFS. And finally, you can just move/delete files without all kinds of errors popping up, Git just detects the move or deletion.

I have a local repository of all of the files and history my project, I can commit frequently to the local repository and when I am satisfied about my work, I could send it to a remote, central repository. Having a distributed repository also means that I am never tied to a network/internet connection to use source control.
Also, when the central repository is down, I could just find a team member that has a recent copy and pull down their repository while I wait for the central server to be fixed.

Using the Git Extensions for Windows gave me another nice little productivity nugget: a sensible and (as far as I can tell) complete list of files that need to be ignored while committing changes. Everything from "Thumbs.db" to the Resharper folders is in there, cool.

As I understand it, Git also works great with large sets of files and large teams. The Linux kernel is under Git source control and that's a lot of files and a lot of collaboration.

There are plenty more features that are cool like cherry-picking commits, the built in CVS proxy server, octopus merging, etcetera. If you want to read more, go and have a look at the Git Wikipedia article. There are some great video's on YouTube as well if you want to understand Git better. Remember that on the Windows side, you don't even need to know the command line syntax.

Disadvantages

I really haven't found any disadvantages yet to using Git. Sure, it's a new system and there's a few things to learn, but that's about it. I've only spent about a day understanding Git and I feel very comfortable already.

Of course, once I start using it more often and in a team scenario, I might run into some difficulties, we'll see.

In the next post, I'll show how easy Git is to set-up and use in Windows with Visual Studio (again, unlike for example SVN).