For about two years my entire Git knowledge was add, commit, push, and a sticky note that said "if it breaks, clone the repo again." I'm not proud of it. Every rebase was a small panic, and every merge conflict sent me to the same three Stack Overflow answers.
If you're searching "how to learn Git," you probably don't need another cheat sheet. There are hundreds and they're all fine. What most of us are missing is a picture of what Git is doing, plus some way to keep the commands we look up from leaking out of our heads a week later.
Get the mental model before the commands
Git commands make sense once you know there are three places your changes can live. The working directory is the files on disk. The staging area (Git calls it the index) is what will go into the next commit. The repository is the history of commits.
git add moves changes from the working directory to the index. git commit turns the index into a commit. git restore and git restore --staged move things back the other way. Once I saw it as moving changes between three boxes, half the commands stopped feeling random.
The second idea is that a branch is just a pointer to a commit. That's all it is: a file with a commit hash in it. HEAD is a pointer to the branch you're on. When you commit, the branch pointer moves forward. When you git reset --hard abc123, you're telling the branch to point somewhere else. Commits don't disappear right away when nothing points to them, which is why the next section exists.
Learn reflog before you need it
git reflog is the command I wish someone had shown me in week one. It lists every place HEAD has pointed recently, including the commit you "lost" after a bad reset or a rebase that went sideways. Find the hash from before the mistake, then run git reset --hard <hash> or create a branch on it with git branch rescue <hash>.
Knowing this changes how you learn. Once you know you can undo almost anything that was committed, you stop being scared to try rebase or cherry-pick on a real branch. (Uncommitted changes are a different story. Reflog can't save those, so commit or stash before experimenting.)
Draw the graph
Run git log --oneline --graph --all in any repo with a few branches. It prints the commit history as an ASCII tree. Do it before and after a merge, a rebase and a cherry-pick, and look at what changed.
Merge creates a new commit with two parents and leaves both lines of history as they were. Rebase replays your commits on top of another branch, so they get new hashes and the history looks straight. Cherry-pick copies one commit onto your current branch. Reading about this is fine, but seeing the graph change in a repo you care about is what made it stick for me.
If you want something more visual, Learn Git Branching is a free browser sandbox that animates the commit graph as you type commands. Its levels on rebase and moving work around are the best I've found.
Practice in a throwaway repo
Make a folder, git init, and create a few commits with one-line files. Then break things on purpose. Make two branches that edit the same line and merge them so you get a conflict. Do an interactive rebase with git rebase -i HEAD~3 and squash two commits. Reset too far and recover with reflog. Stash something, switch branches, and pop it back.
Fifteen minutes of this teaches more than an hour of reading, and nobody else's work is at risk.
Turn every lookup into a flashcard
This is the habit that got me past the sticky note. Whenever I search for a Git command, I write the question I was trying to answer and the command on a card.
How do I undo the last commit but keep the changes?
git reset --soft HEAD~1How do I see what's staged but not committed?
git diff --stagedHow do I change the last commit message?
git commit --amendHow do I bring one commit from another branch onto mine?
git cherry-pick <hash>
Then I review them on a growing schedule: a day later, a few days, a week, two weeks. That's spaced repetition. The cards I keep missing come back more often, and the easy ones fade into the background. If you want to see how the scheduling math works, I wrote How to Implement Spaced Repetition (SM-2) in JavaScript.
Phrase the front of the card as the situation you were in, not the command name. "I committed to main by mistake, how do I move it to a new branch?" is something you'll actually face. "What does git branch -f do?" is trivia.
Keep the good explanations somewhere you'll see them again
A lot of what finally made Git click for me came from talks and videos. Scott Chacon's talks on Git internals, and chapter 10 of the free Pro Git book, which he co-wrote, walk through how objects, trees and refs are stored. Great material, and I'd watch a video, nod along, and forget it by Thursday.
That's one of the reasons I built Recl. You share a video, reel, podcast or article to it from your phone or the Chrome extension, and it writes a summary of the key points, with timestamps for videos. It sorts saves into topics, so the Git internals talk and the rebase article land in the same place, and it brings each one back on a spaced schedule (1, 3, 7, 14, 30 and 60 days later) so you see it again before it's gone.
Learn one thing a week
You don't need to know all of Git. Pick one area a week and use it at work. Week one, the three areas plus restore and diff --staged. Week two, reflog and reset. Week three, interactive rebase. Week four, git bisect, which binary-searches your history to find the commit that introduced a bug. That one feels like magic the first time it points at the exact commit.
A month from now you'll still look things up. Everyone does. The difference is you'll be looking up the flag, not the whole idea, and the sticky note can go.
I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.
Top comments (0)