The version control system (VCS) title known as
git suffers from a common issue in the development space—lousy naming. This perpetual issue is summed up in a wide array of jokes, but one common one is:
There are only two hard things in (computer science/programming/etc.): cache invalidation, off-by-one errors, and naming things.
The original quote (I think?) comes from Phil Karlton, a man who is conspicuously absent from Wikipedia other than as an occasional name drop. The joke spun off from it quickly and with incredible velocity. But the point of the joke ties in a few common frustrations in the dev world.
Naming things has always been a problem for engineers and even more for software engineers. The often-abstract nature of the informational world can make naming things problematic when multiple layers of abstraction interact. Upon reflection, many devs will momentarily flashback to horrific moments in their past when they encountered something named
Look... naming stuff is hard, OK? And one thing that often trips people up when they get introduced to the ubiquitous VCS called
git is the confusing naming and functionality of
So if you need a basic explanation of
git because it makes no sense to you—especially if you've been using
git for a while and still don't fully understand it—read on.
The best way to approach the issue of
git's naming problem is by describing what
git is and what it does.
The basic unit of information that
git revolves around is the repository. This is a collection of many smaller units of information:
- A local database of
commits given unique identifying values. These values are hash IDs and make no meaningful sense to our eyes and brains. Each
commitis a read-only snapshot of some file structure and its contents.
- A local database of
names, which includes
branchnames. These names can then be applied to
commits, and the relationship between the name and hash ID becomes manageable for humans to work with. You only need to know the name of this
- A local repository, typically a file system or structure within a file system that the
commits relate to. Remember, a
commitis a snapshot frozen in time. Some
commits are earlier snapshots—some are later. Some might represent the file system or structure in its current state.
There is more about
git to know—especially surrounding repositories—but conceptually, this is how it should be understood. Now we can examine the naming failure that breaks so many people's understanding of
The opposite of
git push is not
Push and pull. Yin and yang. Good and evil. Give and take. Human language often has opposites that can be used to describe things.
git push is the opposite of
git pull, right? That's how language works!
That might be how language works, but that is not how developers naming things works. People are people and make people-mistakes. Factor in what happens when software titles become popular and used everywhere, and something interesting happens—suboptimal design choices made years ago become too entrenched to change.
One of the most common commands to use in
git push. This command calls up another computer somewhere (or your own computer, possibly) and says, "Hey, I have this list of
commits. Here, take it." After that, the developer is done with the
git push process.
What happens to the
commits after that is up to the computer at the other end. Sometimes, the computer waits for someone else to command it to do something, like
branches. At other times, it might do something in an automated fashion. The important thing here is that the
git push command notifies another system of a series of
commits that have been made and their contents and sends that information to the other system.
There is another typical command used in
git, which is
git pull. This command consists of two different parts:
- Run another command to
mergethe commits received from
git pull is a combination of multiple possible commands, with the one requirement being
git fetch. You'll note that the second part of
git pull does not have a built-in inverse found within
git push. The second part requires intervention, either from humans or an automated system.
So what is
git fetch is the opposite of
git fetch reaches out to another computer (or your own computer, if used on local file systems) and asks for a list of
commits and associated information. Whereas
git push reaches out to another system and tells that system what
git fetch reaches out to another system and asks that system what
commits exist. In the same way that
push only consists of one action,
fetch only consists of one action.
There is a lot more to this whole system. What is happening under the hood is more complicated, and properly working with
git requires some more nuanced understanding if you want to become a power user. There are other naming irregularities found when using
git as well—for instance, why is it so often called a
pull request and not a
But the big thing to note in all of this nomenclature nonsense is that the difference between
git push and
git pull is not what is expected given their standard human language equivalents. This naming issue has caused many headaches for people just learning the VCS, and learning about it will go far in helping you work with one of the most popular pieces of software for developers ever created.