The Git Commands You Actually Reach For Daily

I have used Git every working day for years, and I still type maybe twenty commands with any regularity. The rest I look up. That is the honest shape of Git: a small core you know cold, a long tail you Google, and a handful of recovery commands you only learn the day something goes wrong. This guide is built around that reality. It groups the commands by what you are actually trying to do, points out the traps, and leaves you with a searchable reference instead of a wall of syntax.

Staging and committing: the loop you run all day

Most of a Git day is one tight loop. You change files, decide what to record, and write it down.

git status               # what changed, what is staged
git add -p               # stage hunks interactively, not whole files
git commit -m "fix: clamp upload size"
git commit --amend       # fold a forgotten change into the last commit

The command worth forming a habit around is git add -p. Instead of staging an entire file, it walks you through each hunk and asks yes/no. You end up with commits that actually map to one idea, which makes them far easier to review and to revert later if one turns out wrong.

git commit --amend is the small daily lifesaver: you commit, then immediately notice a typo or a stray console.log. Fix it, git add it, and amend. One catch worth burning into memory — never amend a commit you have already pushed to a shared branch, because amending rewrites the SHA and everyone else's history diverges from yours.

Branching: cheap, so use it freely

Branches in Git are nearly free, so the right instinct is to make one for anything you might throw away.

git switch -c feature/login   # create and move to a new branch
git switch main               # jump back
git merge feature/login       # bring the work into main
git branch -d feature/login   # delete it once merged

You will see git checkout everywhere in old blog posts and Stack Overflow answers, and it still works. But git checkout does two unrelated jobs — switching branches and discarding file changes — which is the root of countless "I lost my work" stories. Git 2.23 split it into git switch for branches and git restore for files. Both are clearer about intent, so prefer them in new habits while still being able to read the old style.

Undoing mistakes: pick the right tool

This is where people get hurt, usually because they grab reset --hard when they wanted something gentler. The three resets move different amounts of stuff:

git reset --soft HEAD~1 undoes the commit but keeps your changes staged. The work is right there, ready to recommit.
git reset --mixed HEAD~1 (the default) undoes the commit and unstages, but keeps the files. Your edits survive in the working tree.
git reset --hard HEAD~1 undoes the commit and throws away the changes. This is the one that bites.

Worked scenario: undoing a bad commit, two ways

Say you just committed something broken to main. There are two correct answers, and which one you pick depends on whether you have pushed.

If the commit is still local only, rewind it:

git reset --soft HEAD~1

The bad commit is gone, your changes are back in staging, and you can fix them and commit again cleanly. Nobody else ever sees the mistake.

If the commit is already pushed and other people may have pulled it, do not rewind history out from under them. Instead, record a new commit that cancels the old one:

git revert <sha>

revert creates a fresh commit that is the inverse of the bad one. History stays linear and append-only, so your teammates pull a normal new commit instead of finding their branch rewritten. The rule of thumb: reset for private history, revert for anything that has left your machine.

The panic commands: stash, reflog, and friends

These are the four that have saved me more times than I can count.

git stash shelves your uncommitted work so you can switch context — pull a hotfix branch, then come back:

git stash            # shelve current changes
git stash pop        # bring them back

The trap: plain git stash skips untracked files. A brand-new file you never staged just gets left in place, not stashed. Pass -u to include it: git stash -u. I have watched people stash, switch, and panic because a new file "vanished" when in fact it never moved.

git reflog is the undo button for Git itself. It records every move HEAD makes for roughly 90 days, even moves that "deleted" commits:

git reflog
git reset --hard HEAD@{4}    # rewind to where you were 4 moves ago

Ran git reset --hard and lost work? Deleted a branch by accident? reflog almost certainly still has the SHA. Find the entry from before the mistake, then either reset to it or save it as a branch with git branch rescue HEAD@{4}. The one constraint: reflog is local-only, so do this on the same machine, before garbage collection runs.

git clean -n previews which untracked files a clean would delete before you commit to it — always run the -n dry run first.

Remotes: staying in sync without surprises

Working with others means a steady rhythm of fetch, pull, and push.

git fetch --prune        # update remote refs, drop deleted branches
git pull --rebase        # pull and replay your commits on top, no merge bubble
git push -u origin HEAD  # push and set upstream in one go

The remote command that deserves a permanent place in your muscle memory is the force-push variant. Plain git push --force overwrites the remote unconditionally; if a teammate pushed since your last fetch, their commit silently disappears. Use git push --force-with-lease instead — it refuses to push if the remote has moved since you last saw it, so you only ever overwrite commits you already knew about. The thirty seconds you save typing -f are not worth a half-day digging a colleague's commit out of their reflog. Never -f, always --force-with-lease.

Make it searchable instead of memorized

Here is the thing nobody admits: you are not supposed to memorize all of this. The commands you run hourly stick on their own; everything else you should be able to find in five seconds. That is exactly what the Git Cheatsheet is for — type any word and it filters live across the command, its description, its common pitfall, and the example. Search "depth" and the shallow-clone entry surfaces even though the word only appears in the example. Tap a category chip to scope to just basics, or just undo-and-recovery, when you are onboarding someone new.

Git is one of three things developers look up every single week. If you are also tired of hand-writing ignore rules, the gitignore generator builds a sensible .gitignore from your stack in one click. Pair both with the regex cheatsheet and you have covered most of the "I always forget this syntax" reference work that breaks your flow.

Bookmark the cheat sheet, keep it open in a tab, and stop re-Googling git reset --soft for the hundredth time.

Made by Toolora · Updated 2026-06-13