This post is an excerpt from my new book, Conversational Git. The entire book is available on-line and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think.
I recently had some close friends talk about their hesitation in adopting Git as opposed to continuing to work with Subversion. I’ve used Subversion for many years, and advocated for its use. I have since jumped wholeheartedly on the Git bandwagon, so I wanted to find a way to tell the story of why I made the switch and why I think so much of the open source community is now based around Git and Git-friendly sites like GitHub.
These friends are smart people, and if they’re not convinced about Git, the problem is not them; it’s that they haven’t seen the right argument yet. There’s so much content out there about Git, and much of it is written at a level that’s way higher than my expertise. But in a way, that’s an issue. When you’re first starting out learning something, the questions that you have are way different from the questions an experienced person has. Once you’ve won that knowledge, it’s almost impossible to go back and think about what it was like when you were first learning. That puts you in a bad position to explain to someone else who’s brand new.
Git seems particularly prone to this because it’s based on some pretty complex notions of how to think about version control. In particular, once you internalize the concept of the Directed Acyclic Graph (DAG) that underlies basically everything in Git, you tend to want to explain that to new people because (a) it can help you think about how Git works; and (b) it’s cool. Unfortunately, teaching Git from a DAG perspective is IMHO the worst way to teach it to new users because it suggests to them that they have to thoroughly understand complex concepts from graph theory to use Git effectively. There’s also no question that the Git help pages use Git-specific jargon, which really interferes with non-experts understanding what a command does.
The book adopts a style that should be accessible to new users. It’s informal , with plenty of first- and second-person references. This is not a “dummies” book; I’m not going to talk down to you, and I’m not going to suggest that you shouldn’t learn complex concepts about Git. But I’m going to try to talk about how I use Git and how I see it being used effectively.
I hope the book is interesting and useful and I look forward to feedback.