git checkout

You need to switch to a different branch, or maybe you want to see what your code looked like three commits ago, or you've made changes to a file that you want to discard. git checkout is the command you reach for when you need to move between branches or restore files to a previous state. It's one of the most frequently used Git commands, but it actually does several different things depending on how you use it.

The most common use is switching branches. When you run git checkout feature-login, Git updates your working directory to match that branch, moving your HEAD pointer to point at the latest commit on that branch. Any files that differ between your current branch and the target branch get updated to match the target. If you have uncommitted changes that would conflict with the switch, Git stops and asks you to commit or stash them first.

But checkout does more than just switch branches. You can also use it to create a new branch and switch to it in one step with git checkout -b refactor-auth. This is equivalent to running git branch refactor-auth followed by git checkout refactor-auth, but it's faster and more common in practice. Most developers create branches this way rather than using the separate branch command.

Working with Specific Commits and Files

Sometimes you need to look at code from a specific point in history without creating a branch. Running git checkout a3f5b2c checks out that specific commit, putting you in what Git calls a "detached HEAD" state. This is useful for investigating when a bug was introduced or seeing what the code looked like before a major refactoring. You're not on any branch, so any commits you make won't belong to a branch unless you create one. If you want to build on that commit, create a branch from there with git checkout -b fix-from-old-state.

You can also use checkout to restore individual files from different commits or branches. Say you're working on a feature branch and you realize you need the version of database.config.js from the main branch. Running git checkout main -- database.config.js pulls just that file from main into your working directory. This is particularly useful when you've made experimental changes to a file and want to start over, or when you need to grab a specific file from another branch without merging everything.

The most common use case for this is discarding local changes. If you've been experimenting with api-client.ts and want to throw away your changes and get back to the last committed version, git checkout -- api-client.ts does exactly that. Just be careful—those changes are gone once you run this. There's no undo.

Pull Request Workflows

When working on pull requests, checkout becomes essential for reviewing other people's code. If someone opens a PR from the branch add-user-permissions, you can check out their branch locally with git checkout add-user-permissions (after fetching) to run their code, test it, and see how it integrates with your work. Many teams have a workflow where they check out PR branches locally before approving them, especially for changes that affect critical systems or need manual testing.

Git has started splitting checkout's functionality into more focused commands. git switch handles branch switching, and git restore handles file restoration. These newer commands are clearer about what they do, but checkout still works and most developers still use it out of habit. The functionality is identical—it's just a matter of whether you prefer the traditional Swiss Army knife command or the more explicit alternatives.

The key thing to remember about checkout is that it changes what you're looking at in your working directory. Whether you're switching branches to work on a different feature, grabbing a file from elsewhere, or investigating old code, you're always moving between different states of your repository. Understanding this makes checkout feel less like several unrelated commands and more like variations on the same core idea.