Ditch the Confusion of Git Checkout for the Precision of Switch and Restore

I used to stare at the git checkout documentation and feel like I was reading a riddle. One day I’d use it to jump to a feature branch, and the next I’d use the exact same command to throw away hours of work on a specific file. It felt dangerous—like using a chainsaw to both fell a tree and carve a turkey. Then Git 2.23 arrived and finally split these duties into two specialized commands: switch and restore. Ever since I made the jump, I haven't looked back.

The Overloaded "Swiss Army Knife"

For years, git checkout was the "do-everything" command. It handled branch navigation, branch creation, and file restoration. The problem is that its syntax is ambiguous.

If you have a file named fix-login and a branch named fix-login, running git checkout fix-login forces Git to guess what you want. It usually guesses right, but "usually" isn't a word you want to rely on when your source code is at stake.

The introduction of git switch and git restore isn't just about adding new words to the terminal; it’s about intent.

Moving Around with git switch

git switch is purely for branch management. It doesn't touch files in a way that risks losing uncommitted work unless you specifically ask it to. It’s safer and the flags make way more sense.

Jumping to an existing branch

Instead of the generic checkout:

git switch develop

Creating and switching to a new branch

The old git checkout -b new-feature always felt a bit arbitrary. Why -b? With switch, you use --create (or the short -c), which is much more descriptive:

git switch -c feature/api-integration

Going back to where you were

One of my favorite shortcuts is returning to the previous branch you were working on.

git switch -

It’s a small thing, but it saves so much typing when you're bouncing between a feature and main for code reviews.

Fixing Mistakes with git restore

While switch handles where you are, git restore handles what your files look like. This is where the real safety comes in. git restore is designed to pull versions of files from your index (staging area) or from a specific commit.

Discarding local changes

If you’ve messed up a file and just want it back to the way it was at the last commit:

git restore src/components/Header.js

This is significantly more intuitive than git checkout -- src/components/Header.js. That -- syntax was always a clunky workaround to tell Git "I'm talking about a file path now, not a branch."

Unstaging a file

We’ve all accidentally ran git add . when we didn't mean to. To pull a file out of the staging area without erasing the work you did on it:

git restore --staged config/settings.yml

Bringing a file back from a different branch

Sometimes you want to peek at how a colleague handled a specific file or grab a utility function from another branch without switching your whole environment.

git restore --source feature/validation-logic src/utils/validate.js

Why Bother Switching?

You might be thinking, "My muscle memory is already set on checkout. Why change?"

1. Safety: switch won't accidentally overwrite your files because of a naming conflict between a branch and a path.
2. Clarity: When you see restore in your command history, you know exactly what happened: a file was changed. When you see switch, you know a branch was moved.
3. Better Errors: Because these commands have a narrower scope, the error messages they provide are much more helpful when things go sideways.

The old git checkout isn't going away—Git is famous for backwards compatibility. But just because the chainsaw *can* carve the turkey doesn't mean it's the right tool for the job. Give switch and restore a week of dedicated use; your brain will thank you for the lower cognitive load.