`git restore` Is Better Than Old `checkout` Habits When You Actually Want to Say What You Mean

Why this command matters: Git got easier to reason about the moment it stopped pretending one overloaded command should express every file and branch action you might need.

What git restore is for

Git documents restore as restoring working tree files. That sounds narrow, but it is exactly the kind of narrowness that helps. Instead of using old git checkout habits for everything, restore lets you describe a file-state operation more explicitly.

This matters because developers often want one of three things:

1. discard local working tree changes
2. unstage something from the index
3. restore a file from another commit

These are not branch-switching actions. They are state-restoration actions.

The common local discard case

If you want to throw away working tree changes in one file:

git restore app.py

That restores the file from the index into the working tree.

This is clearer than older checkout syntax because the command itself tells the truth about your intent: you are restoring a file, not checking out a branch.

Unstaging is also first-class

If a file is staged and you want it back out of the index:

git restore --staged app.py

That is a big quality-of-life improvement for people who still reach for more confusing mixed commands out of habit.

And if you want both staged and working tree state reset together:

git restore --staged --worktree app.py

That explicitness is the real win.

Restoring from another source

Git also supports --source, which is where the command becomes especially useful in debugging and comparison workflows:

git restore --source=HEAD~1 app.py

Now you are restoring content from another tree-ish. This is much more honest than remembering some indirect old incantation and hoping it still means what you think it means.

Why this is better than vague checkout muscle memory

checkout used to carry too much conceptual weight: branches, files, detached HEAD states, and more. restore helps because it narrows the mental model. When the task is file-state recovery, the command says so directly.

This matters in teams because readable command history and clear shell habits reduce fear around Git. People debug more calmly when the commands they run describe one thing well.

A practical debugging scenario

Suppose you changed a config file, staged it, changed it again, and now want to back both steps out. A clean flow with restore makes that intent obvious. You do not need to mentally map your problem onto an old overloaded command. You just decide whether the index, the worktree, or both need to be restored.

That is exactly the kind of clarity that lowers Git stress.

What this command does not replace

It does not replace branch switching. That is where git switch is clearer. The point is not that Git added commands for fun. The point is that separating responsibilities makes everyday workflows easier to understand.

Final recommendation

If your old Git habits still use checkout for every file rollback and unstage action, move those habits to git restore. The command is clearer, more focused, and easier to reason about when the job is restoring file state rather than moving around branches.

Sources

• Git restore documentation
• Git cheat sheet