Optimize the Programmer

It doesn't matter how high up you go. You'll always find someone that doesn't understand git. Do not read this as "You can succeed without learning git!" While, that might actually be true, the fact of the matter is, git just isn't that hard, and it can add so much to your workflow. To make things easy on you, I've put together this short list of the 5 most important git commands.

git init

This one is super simple. All it does is initialize a git repository. You can try it yourself right now to see the results. In a terminal, make a new directory, cd into your new directory. Now, run git init. You should now see a folder called ".git/" (If you're in a GUI file explorer, you'll need to make sure hidden files are visible. If you're in the terminal make sure you run ls -a.) This folder contains a bunch of stuff generated and used by git. Congrats! You've just created a git repo. You don't need to worry about what's inside this folder. Just know that the existence of this folder means that all the other git commands will now work from this folder. This brings us to our next command.

git status

This command gives you a bunch of really important info about the state of your repo. It can tell you the current branch or commit hash you are working off of, which changes are staged, and what type of change each change is. Furthermore, it often tells you what to do next. For instance, if I create a new file in my repo called "README.md" (something that you should have, by the way) and then run git status, it will print "Changes not staged for commit:" with your new file listed below, and right nearby, it will say "use "git add …" to update what will be committed." "What is this git add business?" you ask? It's the next most important command of course!

git add

This one can feel a little weird at first because without understanding a basic workflow, it's not obvious why this step is even necessary. You'll see what I mean. The add command stages a change. Why do you even need to stage anything? Imagine you're working on a project with some custom file reader and writer code. You're fiddling around in Reader.cpp and Writer.cpp kind of simultaneously, and you have that magic moment where the writer is working perfectly. Naturally, you then try to read the output of your writer into the reader, and you get hot garbage. At least the writer works though. You want to save your progress but only the good bits (i.e. the writer). You can save the other stuff when you get it working, but for now theirs no point. All you have to do is stage (i.e. select) the good changes, and save. This is what git add enables you to do.

git commit

This is basically your save command. Every time you get some meaningful progress (I actually wrote an entire post on what that means.), you should commit it. Every commit is a new version of your code. This is what really makes a VCS so awesome. You can create a commit for anything you deem important. For the gamers out there, it's like scum saving for software development except no one will look down on you for it.

git checkout

I'm actually a bit reluctant to include this one, but after some serious thinking, it actually has to be included. Let me explain. git checkout allows you to jump around to different versions of your project. Imagine git is a library, and every version of your project is a book. When you want a certain book (or version of your code) you have to check it out of the library. Without this command, you could save as many versions as you want, but you'd have no way to access them, so all would be for naught.

Now, I hesitated to include this command because once you start jumping around to different commits, you open up the entire world of git and all of its potential complexities. For instance, how do you specify a commit? This is a blog post itself. What happens if I go back to an old version and make new changes from that point? This is where git gets complicated, but it also opens the door for all kinds of git magic.

Wrapping Up

I'm sure someone is snickering right now that I forgot about git push and git pull. In fact, these commands were intentionally left out—and for good reason, which I outline in detail here.