git checkout Tutorial

What you will learn

• Understand the core purpose of git checkout Tutorial
• Master the basic usage and common options of 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.
• Understand key concepts: Why it feels overloaded
• Know when to use this feature and when to avoid it

Start with a problem

You're working in a Git repository and need to perform a specific task — but you're not sure which command or option is the right fit, or what this command can and cannot do.

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 switch and restore came 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 modern git restore.
• Check out a historical commit to enter detached HEAD state, suitable for temporary inspection or experimentation.

Diagram view

Input

Branch/commit refPath (optional)Index or HEAD snapshot

→git checkout

Possible changes

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 checkout to 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.

Try it yourself

1. Practice the git-checkout command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• git-cat-file Tutorial
• git cherry-pick Tutorial
• git-cherry Tutorial