Git Branches | git checkout
The git checkout command
git checkout moves between branches created with git branch. When you check out a branch, files in the working directory are updated to the versions stored in that branch, and all new commits are recorded on that branch. You can think of this command as a way to select the line of development you want to work on.
The previous chapter explained how to use git checkout to inspect old commits. Checking out a branch is similar because the working directory is updated to match the specified branch or version. The difference is that changes left in the working directory can become part of project history. In other words, this is not a read-only operation.
Usage
git checkout <existing-branch>
Checks out a branch created with git branch. After this command, <existing-branch> becomes the current branch and the working directory is updated to match it.
git checkout -b <new-branch>
Creates a new branch named <new-branch> and checks it out immediately. The -b flag is a convenient shortcut for running git branch <new-branch> followed by git checkout <new-branch>.
git checkout -b <new-branch> <existing-branch>
Works like the previous command, but creates the new branch from <existing-branch> instead of the current branch.
Additional notes
git checkout is commonly used together with git branch. When you start developing a new feature, create a branch with git branch, then check it out with git checkout. In a single repository, you can switch between features with git checkout and work on multiple features separately.
Git Tutorial: Switching between features in one repository with git checkout
Creating a dedicated branch for each feature provides a workflow that differs greatly from traditional SVN-based workflows. It makes experimental development easier without risking existing functionality, and it also lets you work on multiple unrelated features at the same time. Branches also make it easier to adopt many collaboration workflows.
Detached HEAD
Now that the three common uses of git checkout have been introduced, it is worth explaining the detached HEAD state mentioned in the previous chapter.
As explained earlier, HEAD refers to the current snapshot in Git. When you run git checkout, Git moves HEAD to the specified branch or commit. If it points to a branch, there is no problem. If it points directly to a commit, the repository enters a detached HEAD state.
Git Tutorial: Detached HEAD
This warns that any work done in this state is separated from the rest of the project’s development work. If you start developing a feature in a detached HEAD state and then check out another branch, for example to merge the feature, there may be no branch pointing to that work.
Git Tutorial: Detached HEAD state
The important point is that development work should always be done on a branch, not in a detached HEAD state. This ensures that there is always a reference to your commits. If you are only inspecting old commits, however, you do not need to worry about the detached HEAD state.
Example
The following example shows the basic use of Git branches. When starting work on a new feature, create a dedicated branch and switch to it:
git branch new-feature
git checkout new-feature
You can then commit new snapshots as described in the previous chapter:
# Edit some files
git add <file>
git commit -m "Started work on a new feature"
# Repeat
All commits are recorded on the new-feature branch, independently from the master branch. You can commit as many times as needed without worrying about other branches. To return to the official codebase, simply check out master:
git checkout master
This command shows the repository state from before the feature work began. From there, you can merge a completed feature, create another branch, start work on another feature, or continue working on the official codebase.