Wednesday, August 13, 2008

Git

For about a month and a half, I've been secretly using Git at work for my local source control management. Shhh.

At work we manage code in Perforce, so eventually my code has to work its way back into P4. Still, I now am finding it difficult to imagine working efficiently without using Git on a daily basis, and the thought of continuing to bridge new projects with the P4 repository makes me cringe a little.

Git is extremely powerful partly because it allows you to make fast branches in-place. How many times have you heard this: "I'd like to try that, but I would have to create another Perforce branch because I've got too much going on in my branch right now." I don't know about you, but I've heard it a lot. I've said it a lot. P4 developers on large projects are only going to have one branch because it takes so long to get a second one going. Spinning two all the time doesn't help unless you use it regularly. You don't use the second branch it for a while, you integrate down and you have to recompile everything from scratch. With Git, on the other hand, switching to the branch is in place. So the compiler only has to recompile and re-link the difference between the branches.

Git also has the ability to easily share between peers. Well, that's all it does, actually -- so it can be a downside and an advantage. The good part is that two people sharing their code doesn't require copying files up to a fileshare and copying them back down (lest you want to do file integrations in P4, which aren't very fun).

Git can work completely offline, so you're not dependent on a central server to check in code and share with others. Granted, I don't think the future holds much for "offline" technologies, but for the time being this can be pretty advantageous.

A question arises with git, "Where's the main development line"? In my case, I just integrate it back into our Perforce server using one of the many P4-git bridge scripts. Normally though, it's not always that straightforward to identify "dev line." The issue with Git is there's (potentially) no central server and any checkin from any other Git repository can be pulled over into any other. Github has a nice graph and explanation for how this works.

In practice one can make a central line for their code and let everyone submit to it, just like Perforce. Once you do this, however, the advantages of using git are lost somewhat. The idea of a central gatekeeper who lets code through is lost at that point. Git works really well for open source projects because of this "gatekeeper" concept, however I still am unsure how it would go with a large scale development.

Probably the biggest downside to Git is that it's pretty darn obscure. Apparently the last two years have been spent trying to make it usable by anyone except Linus Torvalds. The Windows ports are relatively poor and non-Windowsy, but they do work.