Git - git-checkout Documentation (2024)

Quiet, suppress feedback messages.

Progress status is reported on the standard error streamby default when it is attached to a terminal, unless --quietis specified. This flag enables progress reporting even if notattached to a terminal, regardless of --quiet.

When switching branches, proceed even if the index or theworking tree differs from HEAD, and even if there are untrackedfiles in the way. This is used to throw away local changes andany untracked files or directories that are in the way.

When checking out paths from the index, do not fail upon unmergedentries; instead, unmerged entries are ignored.

When checking out paths from the index, check out stage #2(ours) or #3 (theirs) for unmerged paths.

Note that during git rebase and git pull --rebase, ours andtheirs may appear swapped; --ours gives the version from thebranch the changes are rebased onto, while --theirs gives theversion from the branch that holds your work that is being rebased.

This is because rebase is used in a workflow that treats thehistory at the remote as the shared canonical one, and treats thework done on the branch you are rebasing as the third-party work tobe integrated, and you are temporarily assuming the role of thekeeper of the canonical history during the rebase. As the keeper ofthe canonical history, you need to view the history from the remoteas ours (i.e. "our shared canonical history"), while what you didon your side branch as theirs (i.e. "one contributor’s work on topof it").

Create a new branch named <new-branch>, start it at<start-point>, and check the resulting branch out;see git-branch[1] for details.

Creates the branch <new-branch>, start it at <start-point>;if it already exists, then reset it to <start-point>. And thencheck the resulting branch out. This is equivalent to running"git branch" with "-f" followed by "git checkout" of that branch;see git-branch[1] for details.

When creating a new branch, set up "upstream" configuration. See"--track" in git-branch[1] for details.

If no -b option is given, the name of the new branch will bederived from the remote-tracking branch, by looking at the local part ofthe refspec configured for the corresponding remote, and then strippingthe initial part up to the "*".This would tell us to use hack as the local branch when branchingoff of origin/hack (or remotes/origin/hack, or evenrefs/remotes/origin/hack). If the given name has no slash, or the aboveguessing results in an empty name, the guessing is aborted. You canexplicitly give a name with -b in such a case.

Do not set up "upstream" configuration, even if thebranch.autoSetupMerge configuration variable is true.

If <branch> is not found but there does exist a trackingbranch in exactly one remote (call it <remote>) with amatching name, treat as equivalent to

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

If the branch exists in multiple remotes and one of them is named bythe checkout.defaultRemote configuration variable, we’ll use thatone for the purposes of disambiguation, even if the <branch> isn’tunique across all remotes. Set it toe.g. checkout.defaultRemote=origin to always checkout remotebranches from there if <branch> is ambiguous but exists on theorigin remote. See also checkout.defaultRemote ingit-config[1].

--guess is the default behavior. Use --no-guess to disable it.

The default behavior can be set via the checkout.guess configurationvariable.

Create the new branch’s reflog; see git-branch[1] fordetails.

Rather than checking out a branch to work on it, check out acommit for inspection and discardable experiments.This is the default behavior of git checkout <commit> when<commit> is not a branch name. See the "DETACHED HEAD" sectionbelow for details.

Create a new unborn branch, named <new-branch>, started from<start-point> and switch to it. The first commit made on thisnew branch will have no parents and it will be the root of a newhistory totally disconnected from all the other branches andcommits.

The index and the working tree are adjusted as if you had previously rungit checkout <start-point>. This allows you to start a new historythat records a set of paths similar to <start-point> by easily runninggit commit -a to make the root commit.

This can be useful when you want to publish the tree from a commitwithout exposing its full history. You might want to do this to publishan open source branch of a project whose current tree is "clean", butwhose full history contains proprietary or otherwise encumbered bits ofcode.

If you want to start a disconnected history that records a set of pathsthat is totally different from the one of <start-point>, then you shouldclear the index and the working tree right after creating the orphanbranch by running git rm -rf . from the top level of the working tree.Afterwards you will be ready to prepare your new files, repopulating theworking tree, by copying them from elsewhere, extracting a tarball, etc.

In sparse checkout mode, git checkout -- <paths> wouldupdate only entries matched by <paths> and sparse patternsin $GIT_DIR/info/sparse-checkout. This option ignoresthe sparse patterns and adds back any files in <paths>.

When switching branches,if you have local modifications to one or more files thatare different between the current branch and the branch towhich you are switching, the command refuses to switchbranches in order to preserve your modifications in context.However, with this option, a three-way merge between the currentbranch, your working tree contents, and the new branchis done, and you will be on the new branch.

When a merge conflict happens, the index entries for conflictingpaths are left unmerged, and you need to resolve the conflictsand mark the resolved paths with git add (or git rm if the mergeshould result in deletion of the path).

When checking out paths from the index, this option lets you recreatethe conflicted merge in the specified paths. This option cannot beused when checking out paths from a tree-ish.

When switching branches with --merge, staged changes may be lost.

The same as --merge option above, but changes the way theconflicting hunks are presented, overriding themerge.conflictStyle configuration variable. Possible values are"merge" (default), "diff3", and "zdiff3".

Interactively select hunks in the difference between the<tree-ish> (or the index, if unspecified) and the workingtree. The chosen hunks are then applied in reverse to theworking tree (and if a <tree-ish> was specified, the index).

This means that you can use git checkout -p to selectively discardedits from your current working tree. See the “Interactive Mode”section of git-add[1] to learn how to operate the --patch mode.

Note that this option uses the no overlay mode by default (see also--overlay), and currently doesn’t support overlay mode.

git checkout refuses when the wanted ref is already checkedout by another worktree. This option makes it check the refout anyway. In other words, the ref can be held by more than oneworktree.

Silently overwrite ignored files when switching branches. Thisis the default behavior. Use --no-overwrite-ignore to abortthe operation when the new branch contains ignored files.

Using --recurse-submodules will update the content of all activesubmodules according to the commit recorded in the superproject. Iflocal modifications in a submodule would be overwritten the checkoutwill fail unless -f is used. If nothing (or --no-recurse-submodules)is used, submodules working trees will not be updated.Just like git-submodule[1], this will detach HEAD of thesubmodule.

In the default overlay mode, git checkout neverremoves files from the index or the working tree. Whenspecifying --no-overlay, files that appear in the index andworking tree, but not in <tree-ish> are removed, to make themmatch <tree-ish> exactly.

Pathspec is passed in <file> instead of commandline args. If<file> is exactly - then standard input is used. Pathspecelements are separated by LF or CR/LF. Pathspec elements can bequoted as explained for the configuration variable core.quotePath(see git-config[1]). See also --pathspec-file-nul andglobal --literal-pathspecs.

Only meaningful with --pathspec-from-file. Pathspec elements areseparated with NUL character and all other characters are takenliterally (including newlines and quotes).

Branch to checkout; if it refers to a branch (i.e., a name that,when prepended with "refs/heads/", is a valid ref), then thatbranch is checked out. Otherwise, if it refers to a validcommit, your HEAD becomes "detached" and you are no longer onany branch (see below for details).

You can use the @{-N} syntax to refer to the N-th lastbranch/commit checked out using "git checkout" operation. You mayalso specify - which is synonymous to @{-1}.

As a special case, you may use A...B as a shortcut for themerge base of A and B if there is exactly one merge base. You canleave out at most one of A and B, in which case it defaults to HEAD.

Name for the new branch.

The name of a commit at which to start the new branch; seegit-branch[1] for details. Defaults to HEAD.

As a special case, you may use "A...B" as a shortcut for themerge base of A and B if there is exactly one merge base. You canleave out at most one of A and B, in which case it defaults to HEAD.

Tree to checkout from (when paths are given). If not specified,the index will be used.

As a special case, you may use "A...B" as a shortcut for themerge base of A and B if there is exactly one merge base. You canleave out at most one of A and B, in which case it defaults to HEAD.

Do not interpret any more arguments as options.

Limits the paths affected by the operation.

For more details, see the pathspec entry in gitglossary[7].