- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git checkout Tutorial
Explains git checkout as the older multi-purpose command for branch switching and path restoration, and how it relates to switch and restore.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
The short version
git checkout is the classic multi-purpose Git command that can both switch branches and restore paths.
Why it feels overloaded
Because it does two different jobs, newer Git versions introduced git switch for branch movement and git restore for path recovery.
Two common uses
Switch branches
git checkout main
git checkout -b feature/login
Restore a path
git checkout -- README.md
That restores the file in the working tree from the index, similar to what git restore README.md expresses more clearly today.
Checking out a commit
git checkout <commit>
This puts you into detached HEAD, which is useful for inspection but easy to misuse if you forget to create a branch for work you want to keep.
Why you still need to understand it
- many older tutorials still teach it
- old scripts and internal docs still use it
- it helps explain where
switchandrestorecame from
What problem this command solves in a workflow
git checkout is the classic multi-purpose command that handles both "switching branches" and "restoring paths." It affects both the working tree and the HEAD reference — when switching branches it replaces working tree files and moves the current ref, and when restoring paths it overwrites files in the working tree from the index or a specific commit.
Typical use cases
- Switch to an existing branch or create a new one (
git checkout <branch>/git checkout -b <new>), updating working tree files to match the target branch. - Restore a file to the index version (
git checkout -- <path>), discarding unstaged changes in the working tree — this is the predecessor of moderngit restore. - Check out a historical commit to enter detached HEAD state, suitable for temporary inspection or experimentation.
Diagram view
Branch/commit refPath (optional)Index or HEAD snapshot
HEAD ref targetWorking tree file contentDetached HEAD state
Because it does two different jobs, newer Git introduced switch (for branches) and restore (for paths) to split the responsibilities.
Special cases and boundaries
- Using
git checkoutto restore paths will directly overwrite uncommitted local changes — always confirm before doing so. - After checking out a commit you enter detached HEAD; if you keep committing without creating a branch, those experimental commits are easy to lose.
- When an argument could be either a branch name or a path, use the
--separator to disambiguate:git checkout -- <path>. - When the working tree has uncommitted changes, Git will refuse a branch switch to avoid overwriting — you need to commit, stash, or discard changes first.