Git for earthlings

Git is an interesting program for two reasons. One is how it got people to think it's cool. It's a source control program, which is the most boring thing ever. It keeps records of changes, allows undo's, and -- this is the most exiting part -- alerts you when 2 people change the same thing at the same time. Wowie! The other interesting thing is the terms it uses. They're the worst. They're worse than the worst. They go from "no human would use that word in that way" to "we tested every word in the dictionary, then accidentally used the results backwards".

If Git became popular despite names this horrible, it must be really good!


In English, a branch is when something splits. It's the same in computer-speak: because the developers couldn't agree, a program has branched into 2 versions, each missing features the other has. Git is more liberal with the term. In Git a branch doesn't go 2 ways, it goes one way. Branch is another word for "working copy". Every day of normal programing starts by typing the branch command.

A typical conversation: "Are you making normal progress?", "Sure am. I'm working on a branch.", "I hope you're documenting everything." "This is actually my 3rd branch of the day." "Good, good."


In English a repository is a central storage area. As a computer term it's the same. Computers have places that are areas, but aren't central or aren't storage, and as a consequence aren't named repositories. That may sound complex, but anyone who grew up using human language does it unconsciously. The Git team, on the other hand, decided that repository means "any copy of the project". Your actual repository is a repository, but so is the copy your the intern made. There's no special word for the main repository.


Git repositories can be local or remote. You might think that distinguishes them by purpose. Nope. Whichever one you're using now, that's local. There's no such thing as a repository which simply is remote. I don't know why people enjoy these terms. If a command or whatever include the address of another repository, "remote" is redundant.


The term check-out applies to limited resources. For example, we check-out books because no one else can read them while you've got them. The book is out, and where it's out has been checked. Thus the term check-out. If no one needs to know whether you're using something, there's no check-out. Unless you're Git. In Git you checkout a branch to make it your working area. No one else is notified or prevented from "checking it out" themselves. A git check out is missing both things that make it a check-out. Sure, "select" would be a better term, but where's the fun in that? When you check something out it feels like you need to get the most use of out it before it's due back. Checking a thing out revs you up. They were going to name the command weekend pass to the stud farm, which makes as much sense as check-out, but that was a little too exciting.

This also gives us stash. In any program when you switch working areas, you can save what you had, toss the changes, or sometimes you can leave it as is -- not saved, but there if you want to keep going. To do that last thing in Git you stash the changes. That's a good word -- a hasty temporary hiding spot. But does "leave it as it is" even need a special word?


Occasionally I'll think about a word and wonder if it means what I think it does. I've always used "commit" for point-of-no-return. In a computer it's another word for "save these changes". What has me confused is that in Git, "commit" is the second step of three for a save. As in the common phrase "honey, I'm all the way in this relationship, but you're only mid-way, you're merely committed". Git actually calls certain objects commits. You bundle your changes into a commit, which you can then use to save.

That process also brings us abuse of the word "add". Everything in a version control system is about adding to the project, changing, or deleting. But mostly adding. If you're going to name a command add, you'd want to pick the most add-y of the bunch. But Git likes to mix things up. The add command is the first step in a commit. It tags files to be used in a commit. Used in a conversation: "I asked you to add eggs to the cart, where are they?","I added them, but you never asked for the 2 additional steps, so of course they aren't there".

Maybe I'm being hard on git here. add fully adds changes to the commit staging area. It's not as if they could have named the command stage. This late in the game a git command that did what it said would just be confusing.


Git allows several set-ups, each with a different way of saving changes. In "I'm the boss" mode you work on your repository and push your changes to everyone else.

If you're not the boss, or if you like a more detailed history, you instead use a pull. To be clear, you don't pull anything. The command to push your changes is perversely call pull. Here's why: Git isn't about locking files on check-out, it's about resolving conflicts after they occur. When a minion pushes their changes it's a request. If you were asking for permission it would be a push-request, but you're asking them to do it for you. You're requesting that they pull. A pull-request, get it? Naturally, that's shortened to simply "pull".

Kill me now

That all sounds complicated, but it's easy. To do some programming, you make a branch which isn't a branch, then check it out, which doesn't check it out. To save your work you: add the changes, create a commit, and send it in a pull-request. Once you become comfortable with that, the aliens who named things in Git will nominate you as their ambassador. The job requirements mention you being "playfully spent" which meaning will be completely clear to you by then.