Git commands every backend engineer uses under pressure — and the ones they forget

Not a tutorial. The 12 commands that matter when production is on fire.

There are two kinds of git knowledge.

The first kind you build over years of normal work: commit, push, pull, branch, merge. These become muscle memory. You run them without thinking. They work until they don’t.

The second kind you acquire in incidents. A reset that moved the wrong pointer. A rebase that went sideways at 11pm. A branch deleted before the PR was merged. A merge conflict in a hotfix while the monitoring dashboard is red.

The second kind does not appear in tutorials because tutorials are written for conditions that do not exist in production — unhurried, low-stakes, with time to think.

This is the list I wish I had had before my first production incident. Not the commands you use every day. The ones you forget exist until the moment you desperately need them.

The 12 commands

1. git reflog

What it does: Shows every position HEAD has been in, locally, in reverse chronological order. Every commit, reset, rebase step, checkout.

When you reach for it: Anything that looks like lost work. Hard reset to the wrong commit. Deleted branch. Bad rebase. Commits that “disappeared.”

git reflog
# find the hash you need
git reset --hard HEAD@{3}

Why engineers forget it: It is not in the normal workflow. You only need it when something has gone wrong, which means by the time you need it, you are already in panic mode. The engineers who stay calm in git incidents have usually practiced this before they needed it.

2. git revert <hash>

What it does: Creates a new commit that is the exact inverse of the target commit. Removes everything the bad commit added, restores everything it removed. History stays intact.

When you reach for it: Rolling back a bad production deploy when the branch is shared. Never use reset on main. Use revert.

git revert a3f92c1
# creates a new "revert" commit — push and deploy

The distinction that matters: reset rewrites history and is dangerous on shared branches. revert adds to history and is always safe. In production incidents on shared branches, the answer is almost always revert.

3. git add -p

What it does: Stages changes interactively, hunk by hunk. You see each diff chunk and decide: stage it, skip it, split it further.

When you reach for it: Every hotfix. Every time your working directory has more changes than the fix you are trying to ship.

git add -p
# y = stage this hunk
# n = skip this hunk
# s = split into smaller hunks

Why it matters under pressure: When you are writing a hotfix in an incident, your working directory may have unrelated debug statements, experimental changes, half-finished work. git add -p means you stage exactly the four lines that fix the bug and nothing else. The alternative is accidentally shipping debugging code to production.

4. git stash push -u -m "description"

What it does: Saves your working directory state, including untracked files (-u), with a meaningful message, so you can switch context without losing work or committing unfinished code.

When you reach for it: An incident comes in while you are mid-feature. You need to switch to a hotfix branch immediately.

git stash push -u -m "wip: refactoring OrderService validation"
git checkout main
git checkout -b hotfix/payment-null-response
# fix, merge, deploy
git checkout feature/order-refactor
git stash pop

The flag engineers forget: -u includes untracked files. Without it, new files you have created but not yet staged are left behind when you switch branches, and they pollute the hotfix branch.

5. git bisect start / good / bad

What it does: Binary search through commit history to find the exact commit that introduced a regression.

When you reach for it: A bug exists in production. You do not know which of the last N commits caused it. The stack trace is not pointing at a specific recent change.

git bisect start
git bisect bad                    # current state is broken
git bisect good v2.3.1            # this release was clean
# git checks out the midpoint commit
# test whether the bug exists
git bisect good                   # if this commit is fine
git bisect bad                    # if this commit is broken
# repeat until git identifies the culprit commit
git bisect reset                  # return to HEAD when done

The math: For 100 commits between good and bad, bisect finds the culprit in 7 steps. Manual searching through 100 commits is hours. Bisect is minutes.

6. git cherry-pick <hash>

What it does: Applies the changes from a specific commit onto your current branch, as a new commit.

When you reach for it: A fix was merged to main but you need it on a release branch that has diverged. Or you need one specific commit from a feature branch without merging the whole branch.

git checkout release/2.3
git cherry-pick e7d1b44

The mistake engineers make with it: Cherry-picking creates a new commit with a new hash. If you later merge the original branch, you get a duplicate commit. Use it for targeted backports to stable branches, not as a substitute for proper merging.

7. git push --force-with-lease

What it does: Force-pushes your branch, but only if the remote branch is exactly where you expect it to be. If someone else has pushed since your last fetch, it refuses instead of overwriting their work.

When you reach for it: After a rebase on a feature branch that has already been pushed. Or after an interactive rebase that rewrote commit messages.

git push --force-with-lease origin feature/my-branch

Why never git push --force: Plain force-push overwrites whatever is on the remote, including commits from teammates who pushed while you were rebasing. --force-with-lease is a safety check. There is essentially no situation in a team environment where you should prefer --force over --force-with-lease.

8. git log --oneline --graph --all

What it does: Shows the full commit graph across all branches, condensed to one line per commit, as ASCII art.

When you reach for it: You need to understand the actual state of the repository — which branches diverged, where main is, where your branch is relative to it, which commits have not been merged.

git log --oneline --graph --all

Why the flags matter: --oneline removes noise. --graph draws the branch structure visually. --all includes remote branches. Without --all, you only see branches that are locally checked out, which can make the repository state look much simpler than it is.

9. git diff main...feature/my-branch

What it does: Shows the diff between the point where the feature branch diverged from main and its current state — exactly what would be added if you merged this branch.

When you reach for it: Before a PR merge. Before a hotfix deploy. Any time you want to know precisely what changes are about to go to production.

git diff main...feature/my-branch
# three dots = changes since divergence point
# two dots = all differences between tips

The distinction between two and three dots matters: .. shows all differences between the two branch tips. ... shows only what changed on the feature branch since it branched off. In most cases, three dots is what you want before a merge review.

10. git show <hash>:<path>

What it does: Shows the content of a specific file at a specific commit, without checking out that commit.

When you reach for it: You need to see what a file looked like before a change, or extract a specific version of a file during a conflict resolution.

git show HEAD~3:src/main/java/com/example/OrderService.java
# or pipe it somewhere useful
git show a3f92c1:src/main/resources/application.properties > /tmp/old-config.properties

Why it matters in incidents: Checking out an old commit to look at a file changes your working directory and HEAD, which can create confusion in an already chaotic incident. git show lets you read historical file content without moving anything.

11. git reset --soft HEAD~1

What it does: Undoes the most recent commit, keeping all the changes staged. The commit disappears but the work remains, ready to recommit differently.

When you reach for it: You committed too early, committed to the wrong branch, or want to amend the last commit with something you forgot.

git reset --soft HEAD~1
# changes are now staged, uncommitted
# recommit, add more changes, or move to a different branch

The spectrum of reset: --soft keeps changes staged. --mixed (default) keeps changes unstaged. --hard discards changes entirely. In almost every case where you want to undo a commit without losing work, --soft is the right flag. --hard is for when you want to throw away work deliberately, which should be rare.

12. git worktree add <path> <branch>

What it does: Checks out a second branch in a separate directory, simultaneously with your current working tree. Two branches, both fully operational, at the same time.

When you reach for it: An incident hits while you are mid-feature with a dirty working directory. You need to work on a hotfix without disturbing your current state, and you want something cleaner than a stash.

git worktree add ../hotfix hotfix/payment-null-response
cd ../hotfix
# fix, commit, push
cd ../main-repo
git worktree remove ../hotfix

Why engineers do not know this exists: It was added in Git 2.5 and almost never appears in introductory material. Once you have used it for an incident, stashing feels primitive by comparison. No context switching, no stash management, no risk of forgetting what was stashed.

The pattern across all twelve

Read back through the list. Notice what these commands have in common.

None of them are about adding features. None of them move code toward production in the normal sense. Every one of them is about recovering state, protecting history, staging precisely, or understanding what is actually true about the repository right now.

The commands you use every day — commit, push, pull, branch, merge — are the commands for when everything is going well. These twelve are the commands for when everything is not going well.

The engineers I have watched stay calm in production git incidents are not smarter. They have a larger set of available responses. When the situation calls for recovery, they know immediately which tool to reach for, because they have thought about it before the incident, not during it.

That is the whole difference. Not intelligence. Preparation.

If you want the full reference — every command with real production examples, the pre-deploy git checklist, and the exact recovery sequences for the four most common git incidents — that is what I built into Git Under Pressure.

→ Git Under Pressure

[embed]Git Under Pressure Most developers don't struggle with everyday Git.They struggle when something breaks.A rebase destroys your branch.A…devrimozcay.gumroad.com

Real workflows. Real recovery. No theory.

I write about what actually happens in backend production systems — incidents, recovery patterns, and the operational knowledge that does not appear in tutorials.

→ Subscribe on Substack

[embed]Devrim's Engineering Notes | Substack Founder @ProdRescue AI I analyze real production failures, senior engineering decisions, and the hidden patterns behind…substack.com