Switching Branches With git switch (and Why checkout Still Works)

For years git checkout did at least four different jobs: switching branches, creating branches, restoring files, and detaching HEAD. One command, four meanings, and a classic footgun - git checkout . throws away uncommitted work, which surprises everyone exactly once.

Since Git 2.23 the jobs are split into two commands with names that say what they do.

git switch is for branches#

git switch main                 # go to an existing branch
git switch -c feature/invoices  # create a branch and move to it
git switch -                    # back to the branch you were just on

The -c flag replaces git checkout -b, and git switch - is the handiest of the lot when you bounce between a feature branch and main to re-run a test suite. If you have uncommitted changes that would be overwritten, switch refuses instead of silently discarding them - the same safety checkout had, but without the file-restoring ambiguity.

git restore is for files#

git restore app/Models/Invoice.php   # discard uncommitted changes to a file
git restore --staged config/mail.php # unstage, keeping the edits

Both remain destructive-or-not in exactly the ways covered in When to Reset, Restore, or Revert - the split just makes the intent obvious when you read a command back in your shell history.

What you can keep doing#

Nothing was removed. git checkout still works everywhere it used to, and plenty of teams never bothered switching habits. The reason to adopt the newer pair is readability: git switch -c feature/x tells the next person (and future you) exactly what happened, while git checkout always needs a second look to see which of its four jobs it was doing.

Worth knowing alongside this: Stashing Changes Without Losing Your Place for the case where you want to switch branches but are not ready to commit, and git switch --detach <commit> for deliberately inspecting an old commit - the tamer cousin of accidentally landing in a detached HEAD.