also update `HEAD` to set the specified branch as the current
branch.
-'git checkout' <branch>::
+'git checkout' [<branch>]::
To prepare for working on <branch>, switch to it by updating
the index and the files in the working tree, and by pointing
HEAD at the branch. Local modifications to the files in the
--quiet::
Quiet, suppress feedback messages.
---[no-]progress::
+--progress::
+--no-progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless `--quiet`
is specified. This flag enables progress reporting even if not
This means that you can use `git checkout -p` to selectively discard
edits from your current working tree. See the ``Interactive Mode''
section of linkgit: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.
--ignore-other-worktrees::
`git checkout` refuses when the wanted ref is already checked
out anyway. In other words, the ref can be held by more than one
worktree.
---[no-]recurse-submodules::
+--overwrite-ignore::
+--no-overwrite-ignore::
+ Silently overwrite ignored files when switching branches. This
+ is the default behavior. Use `--no-overwrite-ignore` to abort
+ the operation when the new branch contains ignored files.
+
+--recurse-submodules::
+--no-recurse-submodules::
Using --recurse-submodules will update the content of all initialized
submodules according to the commit recorded in the superproject. If
local modifications in a submodule would be overwritten the checkout
Do not attempt to create a branch if a remote tracking branch
of the same name exists.
+--overlay::
+--no-overlay::
+ In the default overlay mode, `git checkout` never
+ removes files from the index or the working tree. When
+ specifying `--no-overlay`, files that appear in the index and
+ working tree, but not in <tree-ish> are removed, to make them
+ match <tree-ish> exactly.
+
<branch>::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
+
You can use the `"@{-N}"` syntax to refer to the N-th last
branch/commit checked out using "git checkout" operation. You may
-also specify `-` which is synonymous to `"@{-1}`.
+also specify `-` which is synonymous to `"@{-1}"`.
+
As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
------------
<1> creates a new branch 'foo', which refers to commit 'f', and then
-updates HEAD to refer to branch 'foo'. In other words, we'll no longer
-be in detached HEAD state after this command.
+ updates HEAD to refer to branch 'foo'. In other words, we'll no longer
+ be in detached HEAD state after this command.
<2> similarly creates a new branch 'foo', which refers to commit 'f',
-but leaves HEAD detached.
+ but leaves HEAD detached.
<3> creates a new tag 'foo', which refers to commit 'f',
-leaving HEAD detached.
+ leaving HEAD detached.
If we have moved away from commit 'f', then we must first recover its object
name (typically by using git reflog), and then we can create a reference to
--------
. The following sequence checks out the `master` branch, reverts
-the `Makefile` to two revisions back, deletes hello.c by
-mistake, and gets it back from the index.
+ the `Makefile` to two revisions back, deletes hello.c by
+ mistake, and gets it back from the index.
+
------------
$ git checkout master <1>
------------
. After working in the wrong branch, switching to the correct
-branch would be done using:
+ branch would be done using:
+
------------
$ git checkout mytopic
changes you made since the tip of the new branch.
. When a merge conflict happens during switching branches with
-the `-m` option, you would see something like this:
+ the `-m` option, you would see something like this:
+
------------
$ git checkout -m mytopic