One Fine Git Book: Pro Git


Category: Code
Tags:  book review  git   svn version control  

As long as I’m reading too much, let me suggest that you can skip the couple dozen blog posts and half-dozen books about Git. Read this one introductory blog post and, if git sounds like a good tool for you, you can read one fine book about Git and be thoroughly informed.

I was reading through the blog of one of the GitHub cofounders and an article caught my eye because it described a process very similar to the one that I’ve heard from people who don’t use any version control:

You start your project in a directory named working. As you code, you try to write one feature at a time. When you complete a self-contained portion of a feature, you make sure that all your files are saved and then make a copy of the entire working directory, giving it the name snapshot-0. After you perform this copy operation, you make sure to never again change the code files in the new directory. After the next chunk of work, you perform another copy, only this time the new directory gets the name snapshot-1, and so on.

I like this because doesn’t insult anyone for using a process like this (as I’m occasionally tempted to do). Instead, he sees it as the first step toward the design of a distributed version control system (DVCS) to manage the process. He explains how a version control system encapsulates all the best practices people have learned from decades of coding and collaborating into a reliable software tool.

The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you.

For anybody still on the fence about whether version control is worthwhile, give The Git Parable a read to find out why most developers consider it a necessity. And even if you’re already familiar with version control it’s worth a read to get the basic concepts behind git (like that a commit it not a changeset, as in svn).

If it gets you curious to learn git, the free book Pro Git is the one book you should read. It combines straightforward, readable prose with clear diagrams:

{width=”300” height=”190” style=”float: left”} {width=”300” height=”159” style=”float: left”}

Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.

Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their master branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into master. It’s used to pull in topic branches (short-lived branches, like your earlier iss53 branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.

This book is the best because Chacon finds the right balance between day-to-day interaction examples and exposing the underlying data model. It finds the right balance between “Don’t worry about this magic here” and “and now a discourse on directed acyclic graphs”.

And once you’ve read it, stop. You don’t need to read anything more about git, go forth and code.

Also Considered

The most common negative here is that a work is out of date: Git went from having almost nothing besides man pages from 2005-2007 to an explosion of introductory stuff in 2008 and early 2009. There were also a few significant UI improvements to git in late 2008 and through 2009 — so anything from before then will have a few confusing odds and ends, which is a problem when learning a system that’s already somewhat complex and opaque.

Git Community Book
A close second, the Git Community Book is only slightly less well-structured.
Version Control With Git
A little disorganized (there’s a lot of “X will be explained a few chapters from now”), but the O’Reilly house style you know well.
Git user Manual
Comprehensive and official, but no handholding, this is largely composed of man pages (...“which read like the terse mutterings of pilots wrestling with the controls of damaged airplanes”).
Pragmatic Version Control Using Git
Well-written and includes a nice reference to git-svn. There’s nothing wrong with this book, but Pro Git is newer and has great diagrams.
Learn Git
Well-written (it’s also largely by the indefatigable Chacon) but incomplete.
Git Internals
Scott Chacon’s first excellent introduction, great but less complete than Pro Git. I haven’t seen the screencast.
Git Magic
Fairly comprehensive, but it feels a bit too conversational and doesn’t explain behind-the-scenes fundamentals.
Git for Computer Scientists
“And now a discourse on directed acyclic graphs.” A short article on git’s data structures.
Git Ready
A friendly blog with bite-sized topics, appears defunct.
Randal Schwartz on Git
For too long this was the only beginner intro to git; by the Hooter’s guy.
Linus Torvalds on Git
A fun hour of Torvalds being rude and occasionally awesome, but not any real introduction.
Using Git Without Feeling Stupid One Two
Brief pair of blog posts giving a basic introduction
Git with Rails Tutorial
Outdated and only about deployment.
Understanding Git Conceptually
Basic info on branching, merging, remote repositories, but that’s all.
GitCasts
An outdated and defunct screencast blog.
Git the basics
A good 130m talk on git, but it’s all the data structures before the hands-on.

...and a few dozen other brief blog posts and talks that aren’t worth linking to.