Git Checkout

---

---

The command git checkout permits us to switch between branches or restore files in our working directory to their state in a specific branch or commit.

It supports in project's management and revert changes.

• The git checkout modifies the working directory's files to match the index's version or a specific commit.

• Also, it updates HEAD to switch to the selected branch if no file or path is supplied.

• We can better match our working directory with a particular branch or commit by using this command.

Syntax

git checkout [<branch-name>]

Usage

Git command git checkout serves many purposes. Following are its main uses:

1. Switching Branches − The git checkout command allows us to switch between branches. It moves your working directory and the HEAD pointer to the specified branch.

git checkout [<branch-name>]

2. Checked out to a Specific Commit − This command can also be used to check out to a specific commit by its hash. This puts your working directory in a detached HEAD state.

git checkout [<commit-hash>]

3. Creating a New Branch − Using the following options, the command git checkout -b|-B <new-branch> [<start-point>] creates and switches to a new branch:

git checkout -b|-B <new-branch> [<start-point>]

• -b <new-branch>: This creates a new branch called <new-branch> and switches to it.

  • This is comparable to using git checkout <new-branch> after executing git branch <new-branch>.

  • Additionally, we may specify whether the new branch should track a remote branch by using the --track or --no-track options.

• -B <new-branch>: In the event that the new branch <new-branch> does not already exist, this creates it.

  • The branch will be reset to the given <start-point> if the branch is found.

  • Being a transactional operation, this option will only reset or create the branch in the event that the git checkout (branch switching) is successful.

4. Restoring Files − The git checkout command can be used to restore a specific file to its previous state in a particular commit. It is useful to undo changes without affecting other parts of the project.

git checkout HEAD -- samplefile.txt

5. Tracking a remote branch − Git will generate a new local branch that tracks the remote branch.

git checkout -b <branch> --track <remote>/<branch>

• It modifies HEAD to point to the designated branch and modifies our working directory and index to match the given <branch>.

• We can commit our local changes to the new branch and they will remain intact.

• This is similar to running git checkout -b <branch> --track <remote>/<branch&gt.

  If the <branch> does not exist locally but a remote branch with the same name is identified and --no-guess is not specified.

• The command essentially accomplishes nothing in terms of branch switching if no branch is supplied, but it will show tracking information for the current branch if it is available.

6. Detaching a branch − With the command git checkout --detach [<branch>] or git checkout [--detach] <commit>, we can detach HEAD at a particular commit and work on it. This means:

git checkout --detach [<branch>]
git checkout [--detach] <commit>

• With <commit> as a branch name: --detach checks the branch, but at the tip of the branch, it detaches HEAD.

• With <commit> as a commit hash: It keeps any local modifications intact and detaches HEAD at the designated commit, updating our working directory and index to reflect that commit.

• Omitting the <branch>: Detaches HEAD at the tip of the current branch.

7. Overwriting Files − File contents are overwritten based on the supplied pathspec when the git checkout command is used with different arguments.

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]

• The contents of the index are updated into the working tree in the absence of a <tree-ish>.

• It updates the working tree and the index with the contents of the specified commit or tree when a <tree-ish> is used.

• If -f is used, it is possible to ignore the unmerged elements in the index, otherwise it would fail.

• Options like --ours or --theirs let us check out specific sides of a merge conflict.

• The conflicting merge result can be restored by using the -m option to discard changes.

8. Applying changes as Patch − The git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>] - We can interactively evaluate and apply changes from a particular commit or tree by using the command.

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>]

• We can apply specific change chunks to our working directory by using the -p or --patch option.

• This gives us exact control over the modifications that are integrated into our files.

Options

The git checkout command has the following options:

-q

--quiet

• Git disables command output and feedback messages when the -q or --quiet option is used.

• As a result, the command runs with little output, giving only the problems or essential information no further messages or status updates.

--progress

--no-progress

• The reporting of progress status in Git commands is managed by the --progress and --no-progress flags:

• --progress: Requires that, even when not connected to a terminal, the progress status be given on the standard error stream.

• --no-progress: Turns off output settings and terminal attachment-related progress reports.

--ours

--theirs

• These options allow us to select the file version for unmerged paths from either stage #2 (--ours) or stage #3 (--theirs) when checking out paths from the index.

• Rebase Context: When using git rebase or git pull --rebase, the branch we are rebasing onto (the shared canonical history) is denoted by --ours.

  While the branch we are currently working on (the work of individual contributors) is denoted by --theirs.

• Rebase incorporates the modifications from our branch and regards the remote history as authoritative, which leads to this distinction.

-b <new-branch>

• In Git, the -b <new-branch> option accomplishes the following tasks:

• The new branch {<new-branch>} is created.

• The <start-point>, which may be a commit or another reference, is where the new branch is started.

• Makes the recently generated branch the active branch in our working directory by switching to it.

-B <new-branch>

• The following can be achieved with Git's -B <new-branch> option:

• It starts from <start-point> and generates a new branch called <new-branch>.

  If the branch already exists, it resets it to <start-point>.

• The currently open branch in our working directory is then the freshly created or updated branch.

-t

--track[=(direct|inherit)]

• When a new branch is created in Git, upstream tracking is configured with the -t or --track[=(direct|inherit)] option.

• It automatically names the new branch based on the local section of the remote-tracking branch if -b is not given.

• The automatic naming is skipped and a name can be explicitly supplied with -b if the derived name is empty or missing a slash.

--no-track

• It makes sure that even if the branch.autoSetupMerge configuration variable is enabled.

• Which often sets up tracking by default, the new branch won't have any upstream tracking configuration set up.

--guess

--no-guess

• --guess: By default, Git automatically creates and tracks the branch using that remote if <branch> is not discovered locally but exists in precisely one remote.

  Git resolves ambiguities when a branch is present in many remotes by using the remote supplied by checkout.defaultRemote.

• --no-guess: Disables the automated guessing behavior, which means that if the branch is not found locally, Git won't construct or track it automatically from a remote location.

  Using the checkout.guess and checkout.defaultRemote settings, the default behavior can be changed.

-l

• The -l option in Git makes sure that a reflog is added when a new branch is created.

• The reflog keeps track of the branch's update history, which is useful for monitoring modifications and correcting errors.

-d

--detach

• The -d or --detach checks a commit rather than a branch, enabling examination or testing without impacting any branches.

• When git checkout <commit> is used with a commit instead of a branch name, this is the default.

--orphan <new-branch>

• Originates a new, commit-free branch called <new-branch> from <start-point>.

• A new, isolated history will begin with the first commit on this branch.

• Adjusting the index and working tree to match the <start-point> gives us a fresh start for new commits or a new project.

• This is helpful when launching a project with a blank slate or creating an entirely new history.

--ignore-skip-worktree-bits

• This option guarantees that, when using sparse checkout mode, git checkout -- <paths> updates all specified files in <paths> while bringing back any files that were skipped and ignoring sparse checkout patterns.

-m

--merge

• The --m, also known as --merge: This option allows us to swap branches even if there are local alterations by completing a three-way merge between the destination branch, our working tree, and the current branch.

• Conflicts that emerge stay separate and need to be settled manually.

• When checking out paths from the index, this option also permits rebuilding a conflicted merge; however, it cannot be used with a tree-ish.

• When using --merge, keep in mind that staged modifications can be lost.

--conflict=<style>

• This option works similarly to --merge, except it lets us choose the style in which to present hunks that are in conflict.

• Three styles, "merge" (default), "diff3", and "zdiff3" are possible values that override the merge.conflictStyle setting.

--patch

• Enables the interactive selection of hunks based on the variation between the working tree and a <tree-ish> (or the index).

• Selective discarding of edits is made possible by applying the selected hunks in reverse to the working tree (and the index, if given).

• This option does not support overlay mode and instead runs in no-overlay mode by default.

--ignore-other-worktrees

• The ref can be used by many worktrees by allowing git checkout to proceed even if it is already checked out in another worktree because of --ignore-other-worktrees.

--overwrite-ignore

--no-overwrite-ignore

• --overwrite-ignore: When switching branches, silently overwrites ignored files (default behavior).

• --no-overwrite-ignore: Stops the branch switch in the event that ignored files are found in the new branch.

--recurse-submodules

• Updates every active submodule to match the commit noted in the superproject using the --recurse-submodules command.

  If local changes in a submodule are overwritten and -f is not also used, the checkout will fail.

• --no-recurse-submodules: Does not modify the working trees of submodules; submodules stay unaltered.

--overlay

• --overlay: The default mode in which files from the index or working tree are not removed by git checkout.

• --no-overlay: Deletes files from the working tree and index that do not belong in the <tree-ish>, making sure they match exactly.

Since Git 2.23, git checkout has been split into more specific commands:

git switch (for switching branches). Click here for details.

git restore (for restoring files). Click here for details.