SVN is based on a relic and broken. A fundamental feature of SVN/CVS is that one’s working copy is a subtree of the repository. At some point in the distant past, this made sense. Diskspace and bandwidth were limited and expensive, but times have changed for the better. However, the design and functionality of CVS stems from this core feature. SVN is a major improvement over CVS by including atomic commits, better support for binary files, and using deltas to create branches (making branching and tagging cheap), but it’s still tied to the partial working directory concept.
For an example of why this sucks, checkout some code with SVN. Then do a rm -rf on a directory, followed by a svn status . Hilarity will ensue.
I want my version control to be as out of the way as possible. I don’t want hidden directories everywhere. I don’t want to svn delete, followed by a commit, followed by pulling out the SVN Manual and scracthing my head. I just want to remove the directory. The version control tool should deal. It works for me, not the other way around.
It’s a little thing, but it got under my skin enough to find another solution. I’ve started using Git for all of my personal projects and become a big fan of the tool. Now that I’ve gotten the ranting out of the way, what follows are what I see as the benefits.
*** CAVEAT *** If you want a tool that works like SVN, use SVN. Git is not for you.
The biggest difference between Git and SVN is that Git is distributed version control. Every working copy is full clone of the repository. SVN is hosted on a single server. An SVN working copy is just the current checked out code: nothing more, nothing less.
Distributed version control is a little more complicated, but it gives the user a lot of flexibility. I can start working on a project and version control it on my laptop immediately. When it comes time to share, setting up a hosted repository is trivial, or I can use a site like GitHub to host it for me.
Since I have a local repository I can freely check stuff in without worrying about its impact on other developers. If I do something that I know is going to break IE, or if I haven’t finished my unit tests, I can still commit code so that I can rolllback after the inevitable screw up. However, I don’t have to make the code public until everything is done. It’s like the local history feature in Eclipse, but you don’t need 6Gigs of RAM and a JVM.
Also, since it’s distributed, you can model usage to your team structure. SVN forces you into a situation where you are basically treating your committers as an organized whole, like a development team in a company. Git’s processes were designed to be the version control tool for the Linux kernel. Git is designed to work well with patchsets. Or you can have the team leader responsible for pulling finished code from team member’s trees. Or you can use it (almost) like you would SVN.
The other major benefit of Git is the command line tools are a lot better. git status gives more information than svn status. Most of the tools work on directories as well as files. git log is super flexible and can give you extremely detailed reports.
Obviously, this isn’t an indepth article. These are just the reasons that I keep using Git. Git is not perfect and there are some drawbacks, but I think it’s the best free version control system. Finally, if you are interested in Git, here are a few things to keep in mind to get over the initial frustrations and learning curve:
- Don’t be afraid of committing, there’s no risk
- Everything in Git happens to to the head of your repository branch. This means merges, updates, etc, occur against what you’ve checked in locally
- Always check in before pulling from a remote repository
- You have to pull before you can push to a remote repository
- Git is less intuitive than SVN, but it’s easier to use
- Git is not SVN
- Most operations work on directories
- The GUI tools suck
- The docs were written by the same guys that think man pages are intuitive
