I’ve appreciated when people take the time to write reviews and highlight connections to other good works. This is an in-progress list that I’ll update over the course of the year. Previously: 2014 2015 2016 2017Continue this post
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:
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.
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.
- 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.
After the sections on recursion, scope, closures, currying, and memoization I was surprised not to see a section on the Y combinator, which allows creating recursive anonymous functions. There’s a blog post with a nice derivation, but it seems oddly absent from the book.
I don’t think too much about these few oddities, though, it takes a certain amount of chutzpah to distill a beautiful language from a clunky, heavily-abused language and it’s harmless to see that manifest a bit of quirky style. Mostly I spent my time reading, pondering, and tinkering with the example code. There are some great examples for creating objects and working with the prototypical inheritance, and the array sorting code (p80) is an especially inspiring bit of useful code.
The only serious negative of the book is the incessant and distracting typos. There are countless small code layout issues, bad line breaks in comments (p39), weird indentation (p40), added line breaks in code (p41), occasional camelCase. There are also a few typos in the code segments that will cause weird exceptions or, worse, silent failures. If the book didn’t have so damn much useful content I’d suggest waiting for a third printing to correct these errors (I read the Sept 2008 printing, look for a [9/08] or later in the lower-right corner of the copyright page). The poor copyediting is compounded by O’Reilly’s awful errata page; you can’t filter by printing and it includes many duplicates, making for a frustrating slog through clutter to track down why a particular sample doesn’t run.