How do you actually use Git, in practice?

It’s easy to find tutorials on how to use Git, and what all the various commands do. It’s harder to figure out how you actually use it, in practice.

Why bother?

But perhaps you’re not sold yet. Here’s the one-sentence pitch: Git saves you from the situation where you think “I had this code working, but then I tinkered with it and broke it, and I can’t remember how to get back”. Think of it as a save checkpoint, the mechanic which revolutionised gaming. Or listen to some guy who picked it as one of the essential skills to learn if you work with data or code or computers.


If you’re starting completely from scratch, GitHub (more on that in a second) has a nice collection of resources and tutorials. Another one which made it really click for me was Git Magic.

Basic workflows

Okay, so you’ve read through a basic tutorial or two. Now what? Git is vast and complex, but the parts you actually use day-to-day are very simple.

Starting up

Activate the magic by opening up a terminal window in a new project’s root directory and going like:

$ git init
Initialized empty Git repository in /Users/jamie/ai-powered-by-blockchain/.git/ 

That works in an existing project, too. Same diff. If you’ve got existing work, you can start by saving a snapshot of it:

$ git add .
$ git commit -m "First commit"
[master (root-commit) 10815dd] First commit
31 files changed, etc etc

When you’re starting a new project you’ll probably want to screw around with the .gitignore file too.

The loop

Here’s your basic workflow: step 1, start by doing something.

$ echo "curl" >> 

Whenever you’re ready to save your game, go to step 2: line up what you want to save.

$ git status
 On branch master
 Changes not staged for commit:
   (use "git add …" to update what will be committed)
   (use "git checkout -- …" to discard changes in working directory)
 no changes added to commit (use "git add" and/or "git commit -a")

Just like the hint says, you “stage” whatever you want to save:

$ git add
$ git status
 On branch master
 Changes to be committed:
   (use "git reset HEAD …" to unstage)

Looks good, so it’s time to lock that in.

$ git commit -m "Adjust strategy; Duke & Duke is buying"
 [master 0e993f5] Adjust strategy; Duke & Duke is buying
  1 file changed, 1 insertion(+)

Then return to step 1. Work–stage–commit, there’s your basic loop that you’ll do approximately a million times.

I put a git status instruction after every step there. That’s partly because this is a demo, but really it’s a good habit to get into, because it’s worthwhile to double-check what you’re about to do before you pull the trigger.

Personally I prefer the git commit -m "..." style, where the stuff inside the quotes becomes the title of the commit. You can then see your whole history by going:

$ git log --oneline
 2e681bf (HEAD -> master) Readjust strategy; Sell it, Mortimer
 0e993f5 Adjust strategy; Duke & Duke is buying
 10815dd First commit

The rationale for these things is similar to a code comment: you’re explaining to your future self what you were doing, and (more importantly) why. If you prefer lengthy Javadoc-style comments, you can use git commit by itself, and you’ll be able to write an essay each time.

Occasionally, programmers use commit descriptions that are so terse that they’re literally useless. Wrote code, followed by Did stuff, then Wrote more code. Don’t do that, unless you hate your teammates and life itself.

The cloud

The work–stage–commit loop is completely sufficient to save yourself from dumb mistakes. If you’re working with a team, or just for extra peace of mind, you’ll need to push your commits to GitHub.

GitHub has really easy instructions on how to set up the link between a local folder on your computer and a given repo in their system. Once that’s established, you can follow up a commit with

$ git push origin master

and voilà, your code is now safe if you drop your laptop in the toilet or whatever.

If you’re working with a team, you’ll need to learn about Git branches. The master branch is the default, which is fine for solo projects, but if you’re working with others you’ll usually start a new branch like so:

$ git checkout -b put-branch-name-here

and then do the work–stage–commit cycle like normal. When you do a

$ git push origin put-branch-name-here

then GitHub will prompt you to create a Pull Request the next time you visit the repo webpage. A PR is not part of Git—it’s something that GitHub invented—but it’s how teams and open-source projects handle incoming code.

If you want to use stuff from someone else’s repo, or get a local copy of one of your own, you use git clone GitHub repos have a button in the top right of the main page for a one-click copy of the address you need.

What GUI should you use?

Trick question. The answer is no.

I’m sure you’re aware of a certain subset of programmers who like to do everything via the command line. “I do all my work in emacs, and I never touch the mouse. It’s so much more efficient and rational this way, etc etc”. This is not that.

The command-line version of Git is pretty simple once you get used to the basic workflow loop. More importantly, GUI wrappers over Git are convenient for a while but they will inevitably screw up your repo, either through a bug or because you clicked the wrong button widget thingy. They’re not worth it.

And now I will simply… Oh no.

Speaking of screw-ups, here’s a secret that Intro To Git tutorials won’t tell you: in practice, everyone fucks up constantly. I’m talking about professional software engineers, with many years’ experience, totally fucking up their work through unforced errors and dumb mistakes.

So don’t feel bad if you commit the wrong file, or commit the right file to the wrong branch, or try to merge two branches and accidentally delete one, or overwrite the master branch instead of merging a change into it, or push a commit with an embarrassing typo in the description, or anything else. We’ve all done that stuff, many times over.

The good news: it’s always recoverable. But you have to know how.

Whatever you do, don’t read the offical docs. They’re written for aliens who live in the 11th dimension. I challenge you to tell the difference between an actual Git documentation page and the Git man page generator.

Just google whatever your specific fuckup is, and the first result will be a StackOverflow question with 10,000 upvotes where someone had your exact problem, no matter how obscure. The accepted answer, with 50,000 upvotes, will patiently set out the 1-3 git commands you need to run to completely fix your problem. God bless StackOverflow.

The only dangerous mistake

There’s only one screwup that people do regularly which is hard to recover from, and important to be careful of. Don’t ever include a secret—meaning a password, an API token, that sort of thing—in a git commit. An easy way to work around that is to keep all your secrets in one file (like, eg, a bash script which sets environment variables) and add that to your .gitignore as soon as you create it.


Git is a true rarity: something we can’t live without, which also teaches you that life is suffering.

I hope these tips have been useful. Please tell me if you have suggestions or feedback. And remember: commit early, commit often.