Getting Started

What Is Git?

Version control software (also known as version control system, or VCS) is a class of programs, like Git, SVN, or Mercurial, used to create and manage versions of files. The most common use case is to allow programmers to work on the same code files without the risk of overwriting each other's changes. VCS usually comes with operations to check in changes, undo changes, and browse history.

Git is a distributed version control system originally optimized for code (specifically the Linux kernel), and it has become ubiquitous in the software development world. It is used to version code, images, and even some binary files (more on them later). Historically, VCS has required people working on a project to check their changes into a centralized hub server, which they would consider the “source of truth.” If your code was not on that one server, nobody else could see it, and it would not get into the main project.

Over time, that centralized process became a bottleneck. Anytime you wanted to make a change or run the code, you had to reach out to a server (which usually took time). Then, if you needed to make more changes, you would have to reach out again for the latest version. Distributed VCS was invented as a response to that bottleneck. Now, instead of only checking out the latest version of the code, Git is “distributed” — which means everyone has a fully copy of all the code with all its history.

Distributed VCS has a couple of important benefits. First, it means that if something goes wrong and your centralized server goes down, your engineers can continue working, because they already have “all” the code (they can sync back up later.) It also means that developers can complete operations locally on their machines, because they do not have to reach out to a server for every operation. There are even implications for disaster recovery, because if the main server goes down, everyone who has the code locally has the full history and can stand up a new server.

Despite these benefits, distribution also has some problems. The biggest one is that when checking out a large project with a large amount of history, you still have to download the whole project. As a result, checkouts are longer than they otherwise might be. In practice, this isn't often a problem.

What Does Git Do Well?

Fail Over

Fail over is a huge feature of all distributed version control systems, not just Git. Mistakes can happen, and at some point, someone is bound to make a bad change to your project. Because every copy of the project is a full copy of everything (including all history), if someone makes a mistake (e.g., deletes something important, introduces a bug, etc.), anyone who has the project checked out can easily push the correct version to wherever it should be, undoing the mistake.

History Rewriting

One of Git’s main features is also one of the things about it that people fear the most. While most version control systems force you to walk forward (without any way to remove something from the project history), Git offers a plethora of tools to rewrite the project history. Check something in on accident? You can fix it. Commit something that didn't work the way you thought it did? It can go away. Check in lots of versions while prototyping, and now the history is unintelligible? There are tools for squashing them down! There are even tools to help you rewrite the history to make feature work appear sequential. That way, you can’t mix up commits for different features with each other.

Multiple Use Cases

Another major advantage of Git is that it is a fairly minimalist tool. It comes with few opinions, so you can adapt it to work with many different workflows of varying complexity. If you have a process you are trying to implement, you can probably adapt Git for that purpose.

What Does Git Do Poorly?

Git is an awesome tool, but it has some significant problems, especially when you’re just starting out with it.

Confusing UI

The commands that the git CLI (and by extension, all GUI tools) implement are confusing. Staging, adding, committing, pushing, pulling, rebasing, checking out? Few of these commands actually have consistent conventions around their naming, and several of them do radically different things depending on the parameters you call on them (checking out a branch versus a file, for example). The commands are not arbitrary, but they are not easy to think through until you completely understand Git. This confusing UI frustrates a lot of beginners, even those with other VCS experience.

History Rewriting Can Confuse Users

Alas, one of Git’s best features, history rewriting, can also be one of its biggest problems. It is always possible to get yourself out of a bad situation in Git, thanks to its forgiving garbage collector, but many people are afraid to dip their toes into history rewriting, simply because it isn't always obvious how to recover from a bad situation.

So why learn Git?

Hopefully this article answers some of the background questions that you might have about what Git is and why one might chose it instead of other VCS. In future posts, I hope to dig more into how Git works and share some tools I have found useful in my work.