Photo by RoonZ nl on Unsplash

So I was three hours into a code review last week when a junior dev on my team asked me how to undo a commit they'd already pushed to main. They'd been Googling for 20 minutes. Meanwhile I typed one command and it was done. That interaction reminded me how much of git is just... tribal knowledge. Stuff you pick up from a grumpy senior dev or stumble across at 2am when something's on fire. So here's a bunch of it, written down.

These git tips aren't sorted by difficulty or anything like that — just stuff that's genuinely useful, roughly in the order I thought of it.

Fix your last commit without making a new one

You commit something, then realize you forgot a file. Or you typo'd the commit message. Instead of making a gross second commit that says "oops forgot file" — just do this:

git add forgotten-file.js
git commit --amend --no-edit

The --no-edit flag keeps your original message. Drop it if you want to change the message too. Just don't amend commits you've already pushed to a shared branch unless you enjoy angry Slack messages.

The stash is more powerful than you think

Most people know git stash exists. Far fewer people use it well. Here's the thing though — if you're just running git stash with no arguments, you're leaving features on the table.

Name your stashes so you can actually find them later:

git stash push -m "wip: auth refactor before hotfix"

Then list them:

git stash list

And apply a specific one by index:

git stash apply stash@{2}

I've seen people stash things and then just... never recover them because git stash pop applied the wrong one and they panicked. Use named stashes. Future you will be grateful.

Aliases that I literally use every day

Honestly, if you're not using git aliases, you're just typing more than you need to. Throw these in your ~/.gitconfig under the [alias] section:

[alias]
  st = status
  co = checkout
  br = branch
  lg = log --oneline --graph --decorate --all
  undo = reset HEAD~1 --mixed

That lg alias is the one I show everyone. It gives you a compact, visual branch graph in the terminal. Way better than staring at a wall of full commit metadata. And undo is exactly what my junior dev needed — it rolls back your last commit but keeps the changes in your working directory so you don't lose anything.

Cherry-pick is not cheating

Sometimes you only need one specific commit from another branch. Maybe a hotfix, maybe one feature. You don't need to merge the whole branch. This is what cherry-pick is for and for some reason people treat it like it's dangerous or dirty.

git cherry-pick abc1234

Just grab the commit hash from git log or your git GUI and you're done. Works great for backporting fixes to release branches.

Here's an insider one: interactive rebase for cleaning up before a PR

Okay this is the one that separates people who've been doing this a while from people who are still learning. Before you open a pull request, your commit history probably looks like: "initial work", "fix", "fix again", "actually fix", "okay now it works". That's embarrassing. Clean it up with:

git rebase -i HEAD~5

Replace 5 with however many commits you want to look at. An editor opens and you can squash commits together, reorder them, or reword messages. Change pick to squash (or just s) on the commits you want to fold into the previous one. The result is a clean, readable history that doesn't make reviewers sigh.

Side note — I'd argue good commit hygiene is one of those things that's genuinely hard to teach but makes a huge difference when you're debugging something six months later and trying to figure out why a change was made.

Find exactly when a bug was introduced with git bisect

This one feels like magic the first time you use it. git bisect does a binary search through your commit history to find exactly which commit introduced a bug. You tell it which commit is known-good, which is known-bad, and it walks you through the middle commits asking "good or bad?" until it pins down the culprit.

git bisect start
git bisect bad                  # current state is broken
git bisect good v2.1.0          # this version worked fine

Git checks out a commit in the middle. You test it, then type git bisect good or git bisect bad. Repeat until it identifies the exact commit. Run git bisect reset when you're done to get back to your branch.

In my experience, most devs have never used this and instead spend an hour manually checking out commits one by one. Don't do that.

See what you actually changed before committing

Quick one but super useful. git diff shows unstaged changes. But to see what's already staged and about to be committed:

git diff --staged

Obvious in hindsight but I've caught embarrassing things (debug logs, commented-out passwords, a console.log that says "WHY IS THIS BREAKING") right before committing them, just by making this a habit.

Set a global .gitignore for your editor junk

Every project shouldn't have to ignore your .DS_Store files or your .vscode/ folder. Set it once globally:

git config --global core.excludesfile ~/.gitignore_global

Then put your editor/OS-specific ignores in ~/.gitignore_global and never worry about it per-project again. This is one of those things that takes 90 seconds to set up and pays off forever.

Hope this saves you some time — or at least gives you something useful to show the next person on your team who's Googling how to undo a commit.