Why This Book
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.
Style and Motivation
I’m hoping in this book to adopt a style that will be accessible to new users. I’m writing in an informal style, 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 it and how I see it being used effectively.
When I first started learning Subversion, there was a book I found incredibly helpful, because it focused on why Subversion chose the copy-modify-merge model instead of the checkout-modify-checkin model. It did this by walking through the tool’s features in a way that followed real usage. I hope to present in a similar way.
I’m making a few assumptions about readers. The first is that readers know in general what version control tools are for, and therefore what Git is for. The second is that a reader of this book is familiar with Subversion or CVS, and is interested in knowing how a “distributed” version control system, and Git in particular, is different. If those assumptions don’t apply to you, I hope you still get value, but you might not get as much.
I’m calling this book “Conversational Git” both because I’m aiming for a conversational style and because, when learning a new language, a key goal is to be “conversational” – able to make basic small talk, even if not quite a native speaker.
Because I wrote this book in a conversational style, it’s verbose (like me!) and breezy. So I hope it’s a quick read. I do include a bunch of Git commands in here. If you choose to follow along running those commands, you’ll need to be consistent because some later things are based on some earlier things. However, when I read tutorials or books like this, I hate having to follow along typing commands, so I tried to write in such a way that you can just “get” what the commands are doing from the context. So don’t feel like you have to follow along to follow along, if you get my meaning.
For the same reason, the ratio of Git commands to text is somewhat lower than a typical tutorial. I’d rather spend a paragraph explaining or providing motivation for a one-line command than present all the possible switches for all the Git commands. That’s a different book, and Scott Chacon has done a much better job writing that one than I could anyway.
Why Not
I’m not writing this book to argue against Subversion in favor of Git. Like I said, I’ve used Subversion heavily for many years, and I still advocate for it when people are looking for version control tools. Where I compare Subversion and Git, it’s an attempt to discuss tradeoffs from the perspective of someone who likes both tools but tends to use Git by preference.
I’m also not writing this book to advocate for Git versus Mercurial or Bazaar. I’m not qualified to write that book.
Finally, I am not writing this book to refute people’s complaints about Git. In fact, one of the reasons I wanted to write it is because of Steve Bennett’s 10 things I hate about Git, because I agree with him! Using Git is not pain-free; I just happen to think it’s worth it.
Dogfooded
We’ll start the next chapter momentarily, but first, I want to point out that this book is dogfooded. It’s hosted as a Git repository. I’m able to maintain the source of this book through updates to that repository. And the ability to use Git in this way goes far beyond a simple e-book like this one. I wrote the whole of The Book of Kubernetes using LaTeX and the Git support built into Overleaf. Git made it easy to track changes over time and even to collaborate with my editors and reviewers without stomping on each other’s changes. That whole workflow is an essential part of why Git has become so popular for open-source projects, and a key purpose of this book is explaining that workflow and why it’s so powerful.
The book is written using Markdown, processed using Hugo, and published via Netlify.