In iBanjo's Git article, Ben Collins-Sussman makes a funny, but revealing version of the Git documentation. It reveals a lack of understanding fed by dogmatic Git trolls. I love Git, but I certainly hope I don’t come across as a troll.
I am the Subversion administrator at work, but I personally use Git to collaborate with my peers without affecting our quality process or resorting to handing around patches. Surely I should use branches? I do, I simply do not trust Subversion to do merging correctly because it only recently added merge tracking. I’ve been using Subversion since its pre-1.0 days in 2002. Early on, Subversion also fundamentally stated that merge tracking was the user’s responsibility.
Every time we have used Subversion’s branches it has been a complicated ceremony full of fear and risk. I’d just frankly rather use something like Git for my day to day activities because it has treated branching and merging as fundamental use cases from the outset. Subversion does an acceptable job of backing our mainline, but it is beginning to look like more of a liability as our development team grows.
Git works quite nicely with Subversion. It is also significantly faster. Not 20-50% faster, buy tens to hundreds of times faster. While this isn’t a big deal for commits and updates it is a huge deal for forensics during bug fixing. Being able to search the entire history nearly instantaneously for any aspect of a commit is huge and Git provides a GUI for it. Having merges happen in seconds is powerful and changes the way developers work. Simply having working merge tracking is not enough to get developers using it, it needs to be fast and unobtrusive. Subversion does not deliver on speed.
This notion that Git is only for hardcore hackers is antiquated. Do you think GitHub would be anywhere near as successful if Git was actually hard to use?
Last year I scoffed at a new developer’s insistence that Git was an effective SCM. This year I have gained radical productivity advantages from using it. Take the time to read through Scott Chacon’s Pro Git and see whether or not it is a fit before dismissing it.