vi. Introduction

There are usually two reasons a person picks up a book about Git: one, they are unusually curious about how the software works at a deeper level; or two, they’re frustrated and need something to solve their problems now.

Whatever situation brought you here, welcome! I’m happy to have you onboard. I came to write this book for both of the above reasons. I am a tinkerer and hacker by nature, and I love going deep into the internals of software to see what makes them tick. But I, like you, found Git at first to be an inscrutable piece of software. My brain, which had been trained in software development through the late 1990s, found version control packages like SVN soothing, with their familiar client-server architecture, Windows shell integration, and rather straightforward, albeit heavy, processes.

When I came to use Git and GitHub about seven years ago, I found it inscrutable at best; it seemed no matter which way I turned, Git was telling me I had a merge conflict, or it was merging changes from the master branch into my current branch, or quite often complaining about unstaged changes. And why was it called a “pull request”, when clearly I was trying to push my changes into the master branch?

Little by little, I learned more about how Git worked; how to solve some of the common issues I encountered, and I eventually got to a point where I felt comfortable using it on a daily basis.

Enter the video courses

In early 2017, my colleague Sam Davies created a conference talk, titled “Mastering Git”, and from that, two video courses at raywenderlich.com: “Beginning Git” and “Mastering Git”. Those two courses form the basis of this book, but it always nagged me a little that, while Sam’s video version of the material was quite pragmatic and tied nicely into using both the command line and graphical tools to solve common Git workflow problems, I always felt like there was a bit of detail missing; the kind of information that would lead a curious mind to say “I see the how, but I really want to know more about the why.”

This book gives a little more background on the why: or, in other words, “Why the %^&$ did you do that to my repository, Git?!” Underneath the hood, you’ll find that Git has a rather simple and elegant architecture, which is why it scales so well to the kinds of globally distributed projects that use Git as their version control software, via GitHub, GitLab, Bitbucket, or other cloud repository management solutions.

And while GUI-based Git frontends like Tower or GitHub Desktop are great at minimizing effort, they abstract you away from the actual guts of Git. That’s why this book takes a command-line-first approach, so that you’ll gain a better understanding of the various actions that Git takes to manage your repositories — and more importantly, you’ll gain a better understanding of how to fix things when Git does things that don’t seem to make much sense.

How to read this book

This book covers Beginning Git. If you are still struggling to figure out the difference between a push and a commit, or you’re coming to Git from a different version control system, start here. This section takes you through concepts such as cloning, staging, committing, syncing, merging, viewing logs, and more. The very first chapter is a crash course on using Git, where you’ll go through the basic Git workflow to get a handle on the how before you move into the what and the why.

This book works with a small repository that houses a simple ToDo system based on text files that hold ideas (both good and bad) ideas for content for the website. It’s an ideal way to learn about Git without getting bogged down in a particular language or framework.

The next book in our mastering Git series, Advanced Git, which we encourage you to explore once you’ve completed this book.

Workflows

This section takes a look at some common Git workflows, such as the feature branch workflow, Gitflow, a basic forking workflow, and even a centralized workflow. Because of the flexibility of Git, lots of teams have devised interesting workflows for their teams that work for them — but this doesn’t mean that there’s a single right way to manage your development.

Learning by doing

Above all, the best advice I can give is to work with Git: find ways to use it in your daily workflows, find ways to contribute to open-source projects that use Git to manage their repositories, and don’t be afraid to try some of the more esoteric Git commands to accomplish something. There’s little chance you’ll screw anything up beyond repair, and most developers learn best when they inadvertently back themselves into a technical rabbit-hole — then figure out how to dig themselves out.

A note on master vs. main

At the time that this book went to press, GitHub (and potentially other hosts) were proposing changing the name of the default repository branch to main, instead of master, in an attempt to use more culturally-aware language. So if you’re working through this book and realize that some repos use main as the central reference branch, don’t worry — simply use main in place of master where you need to in these commands. If the point comes when there seems to be a consensus on main vs master in the Git community, we’ll modify the book to match.

I wish you all the best in your Git adventures. Time to Git going! — Chris Belanger