push.cx
Peter Bhat Harkins
Getting Git
I’ve been curious about git for a few weeks. I’ve heard friends recommend it, a lot of big projects (Linux kernel, Xorg, Rails) have switched to it, and I hadn’t yet learned a distributed version control system. I’ve bounced off the blog posts I’ve come across, they weren’t well-organized or assumed some basic familiarity I didn’t have. The man pages were also kind of intimidating.
I found an article promising to explain git from the bottom up. It starts out well, with an explanation of the basic objects involved. I puzzled a bit when it started comparing merges, but the graphs made it pretty clear what the difference between a merge and rebase are, though I was fuzzy on why you’d want them or if they were really usable. Then it sort of wandered into resets and reflogs and it wasn’t so much a tutorial anymore as a gripe/exploration of advanced features that went a bit over my head.
I switched to reading Git Internals on a friend’s recommendation. Some minor formatting oddities aside (widows, orphans, and why not put the graphs in the gigantic right margin?), it’s a great introduction to git. Like the previous, it builds from the basic git objects and starts by explaining how files, then directories, then versions are stored. On page 29 it describes creating a branch in a way that connected the bottom-up file-editing step-by-step and how git handles branches in the working copy, and the light went on for me.
I suddenly understood why git stores everything as a directed acyclic graph, how branching and merging are implemented and used, how git handles distributed revisions, and how git achieves such great performance. Almost none of this is mentioned on page 29, that’s just when all the puzzle pieces of a dozen blog posts, the last couple dozen pages, the bits of man pages, and my computer science education on graphs jumped together in a few seconds. These moments of startling clarity are why I love programming so much.
Git a useful tool that I now plan to replace my svn usage with, and it looks like it’ll be great to build tools on top of.
I heartily encourage developers to learn git. Don’t be discouraged if page 29 of “Git Internals” doesn’t mean anything special to you, I know I could have had my insight on page 30 or at 4 AM on Thursday just as easily. Or maybe last year if I had used a dcvs and paid more attention in math classes. About all I can recommend is that you skim whatever you find about it and keep in mind git is closer to a tool for implementing a version control system than a seamless workflow experience (think dd, not FogBugz).