Beyond ‘Punk Rock Git’ in Eleven Steps

Punk Rock Git?

I’ve spent the last couple of years teaching Git, mostly to users that I like to call ‘punk rock’ Git users.

They have three commands, and they can get by with them.

They’re not terribly interested in Merkle trees or SHA-1 hashes, but are interested in what a ‘detached HEAD‘ is, or understanding what a rebase is so they don’t feel intimidated when someone drops it into a conversation.

In fact, a stated primary aim of the course I wrote and run is to get you to fully understand what a rebase is. At that point, you’re a punk rocker no longer.

These git students often say they are bewildered by where to start with expanding their git knowledge. So here, I briefly outline a set of Git concepts and commands, and – crucially – the order you should grasp them in.

I also noted in bold most of the ‘a-ha’ moments I’ve observed experienced but casual users getting when they follow the course.

My book ‘Learn Git the Hard Way’ (which is the basis
of my course and has a similar structure, and with more
optional items covered) is available as a book here.

1) Core Git Concepts

Here’s the baseline of what you want to know before you set off:

Understand that there are four distinct phases to git content
- Local changes
- Staging area
- Committed
- Pushed
Don’t memorise the above, just be aware of it
Branching is cheap compared to other source control tools
All repositories are equivalent in status – there’s no predefined client/server relationship
GitHub is treated as a server by convention by many users – but there’s nothing about Git that forces anything to be a ‘server’. GitHub could be used as a backup

2) Creating a Repository

It’s important to see what a git repository created from scratch looks like:

Creating a git repository is as simple as running git init in a folder
Use git add to add content
Use git status to see what’s going on
Use git commit to commit some content
Use git log to see what the history now says
Have a look at the .git folder and understand the what the HEAD file is doing

3) Cloning Repositories

You’ve created a repository, now see what happens when you clone it:

Use git clone to clone the repository you created above
Look at the .git folder and figure out its relationship to the cloned repository
Delete stuff ‘accidentally’ from your clone and restore using git reset

4) Branching and Tagging

Now create a branch:

Create a branch in a repo and make sure you’ve moved to it
Understand that a branch is ‘just’ a pointer to a commit that moves with each commit
Understand what HEAD is doing
Create a tag
Understand that a tag is a pointer to a commit
Understand that HEAD, branches and tags are all references

5) Merging

You’ve got branches, so learn how to merge them:

Create two conflicting changes on two branches
Try to git merge one with another
Resolve the conflict and git commit
Understand the diff format
- There’s a great exposition here

6) Stashing

If you’re going to branch, you’ll probably want to stash:

Know why stashing is important/why it’s used
Use git stash and git stash pop
Understand that it’s in the git log --all output, and that it’s ‘just’ a branch, albeit a special one

7) The Reflog

Now you know what references are, and have seen the stash, the reflog should make sense quickly:

Use the git reflog command
Understand that the reflog (reference log) logs
Understand that this comes in handy when things go wrong in git, and references have been moved around
Use git reset to revert a change in the reflog using the reference id

8) Cherry Picking

Cherry picking is a nice precursor to rebasing, as they’re (in principle) similar ideas:

Make a change on one of the branches you’ve created
git checkout a change in another branch on the same repository
Use git log to get the commit ID of the change (which looks similar to
05bef161ec563f5a0b3886f2f35a6cab37b06389)
Use git cherry-pick and the ID you just found to port the same change to the other branch

9) Rebasing

Now you’re ready for rebasing!

All through the below you might want to use git log --all --graph --oneline to see the state of the repository and what’s changing:

Create a new branch (B) from an existing branch (A)
Move to that new branch (B)
Create a series of changes on B
Move to the old branch (A)
Create a series of changes on A
Go back to branch B
Use git rebase to update your branch so that its changes now come from the updated end of the A branch

See how all the changes are in a line now?

Go back to the A branch and rebase it to B. What happened?

10) Remotes

In your cloned repo, look at the output of git remote -v
Run git branch -a and see how the remote repository is actually stored in your current repository with a remote reference.
Look at the .git/config file and see how the cloned repository is referenced within this repository

11) Pulling

Now you’ve understood remotes, you can now deconstruct git pull and understand what it does:

Stop using git pull!
Read about, use and learn git fetch and git merge
Understand that when you fetch, you’re talking to a different repo, and then by merging it in you’ve done a ‘pull’
For bonus points, grok that fast-forwards are just the HEAD moving its pointer along to the end of a series of changes without a merge

‘You Missed X!’

There’s plenty more that others might consider essential, eg:

Submodules
Bare repos
Advanced git logging

and so on. But the above is what I’ve found is required to get beyond punk rock git.

You might also be interested in my book Learn Git the Hard Way, which goes into these concepts and others in a more guided way:

You might also be interested in Learn Bash the Hard Way or Docker in Practice

Get 39% off Docker in Practice with the code: 39miell2