DEV Community

max
max

Posted on • Edited on

The Git Commands I Use Every Day (and the Ones I Always Forget)

I force pushed to main once. Second month at my first real dev job. Just sat there watching Slack light up while the senior engineer scrambled to fix what I'd done. He was cool about it. We're still friends. I still feel the shame.

That was the day I stopped treating Git like something I'd "figure out eventually" and started actually learning the commands. Seven years later, I still Google half of them. Not because I'm bad at Git. Because Git has roughly 150 commands with thousands of flag combinations and whoever designed the CLI was apparently allergic to consistency.

So I keep a cheatsheet. Here's what's actually in it.


Commands I Use Every Single Day

You already know these:

git status                    # What changed?
git add .                     # Stage everything
git commit -m "message"       # Commit
git push                      # Ship it
git pull                      # Get latest
git checkout -b feature-name  # New branch
git log --oneline             # Quick history
Enter fullscreen mode Exit fullscreen mode

That covers maybe 80% of my day. The other 20% is where things get annoying.


Commands I Use Weekly (but Can Never Remember the Flags)

Stashing with a message

git stash push -m "WIP: refactoring auth"  # Named stash
git stash list                              # What did I stash?
git stash pop                               # Apply and remove
git stash apply stash@{2}                   # Apply specific one
Enter fullscreen mode Exit fullscreen mode

I forget the push -m syntax every single time. Plain git stash works but then you end up with a list of unnamed stashes and zero idea what's in any of them. Future you will hate past you for this.

Interactive add

git add -p   # Stage individual hunks
Enter fullscreen mode Exit fullscreen mode

This is genuinely the most underused Git command. It lets you stage parts of a file instead of the whole thing. If you've ever had a messy working directory and wanted clean, logical commits instead of one giant "WIP" commit, this is how you do it.

Most people don't know it exists. I didn't for years.

Viewing diffs properly

git diff                      # Unstaged changes
git diff --staged             # What's about to be committed
git diff HEAD                 # Everything since last commit
git diff main..feature        # Branch comparison
Enter fullscreen mode Exit fullscreen mode

I mix up --staged and --cached every time. They're the same thing. --staged is just the modern alias. Why Git has two flags that do the same thing is beyond me, but here we are.


Commands I Look Up Every Time

Undoing the last commit

This one is a pain in the ass to remember because there are three different ways to do it and they all do different things.

# Keep changes (just undo the commit)
git reset --soft HEAD~1

# Discard everything (nuclear option)
git reset --hard HEAD~1

# Undo but create a new "undo" commit (safe for shared branches)
git revert HEAD
Enter fullscreen mode Exit fullscreen mode

Reset rewrites history. Never use it on shared branches. I learned this the hard way (see: the force push story above). Revert creates a new commit that undoes the old one. Safe for shared branches. Use revert if anyone else has pulled that code.

Cherry-picking

git cherry-pick abc123f       # Apply one commit to current branch
Enter fullscreen mode Exit fullscreen mode

I use this maybe twice a month. The syntax is dead simple and I still look it up every time.

Finding what broke things

git bisect start
git bisect bad                # Current commit is broken
git bisect good abc123f       # This older commit was fine
# Git checks out a middle commit - test it, then:
git bisect good               # or git bisect bad
# Repeat until Git finds the breaking commit
git bisect reset              # Done, go back to normal
Enter fullscreen mode Exit fullscreen mode

git bisect is magic. Binary search through your commit history. For a 1000-commit range, it finds the exact commit that broke things in about 10 steps. I wish I'd known about this earlier. Would have saved me a lot of 2am git log scrolling.

Cleaning up merged branches

# Delete local branch
git branch -d branch-name

# Delete remote branch
git push origin --delete branch-name

# Remove stale remote tracking branches
git fetch --prune
Enter fullscreen mode Exit fullscreen mode

Just run git fetch --prune regularly. Your branch list is probably a mess right now. Go look. I'll wait.

The reflog (your safety net)

git reflog                    # Show everything you've done
git checkout -b recovery abc123f  # Recover "lost" commits
Enter fullscreen mode Exit fullscreen mode

Even after a hard reset, your commits aren't truly gone for about 30 days. The reflog tracks every HEAD movement. This is the command that would have saved me from that force push panic at my old job if I'd known it existed at the time. I didn't. The senior dev did, though. That's how he bailed me out.


How I Actually Remember Things

I don't.

The few commands I've memorized are the ones I type 10+ times a day. Everything else, I look up. The trick isn't memorizing all of this. It's having a reference you can search in 5 seconds instead of opening 12 Stack Overflow tabs.

I keep mine organized by what I'm trying to do, not alphabetically by command name. Because when something's broken at 11pm, I'm not thinking "what's the syntax for revert," I'm thinking "how do I undo this commit without destroying everything."

I ended up putting together a Developer CLI Cheatsheet Bundle based on my own reference doc. Git, Docker, Linux, organized by workflow. Honestly built it for myself first and figured other people probably have the same 30-tabs-open problem.

Top comments (0)