--------
[verse]
'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] [--detach] [<commit>]
+'git checkout' [-q] [-f] [-m] --detach [<branch>]
+'git checkout' [-q] [-f] [-m] [--detach] <commit>
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
successful.
'git checkout' --detach [<branch>]::
-'git checkout' <commit>::
+'git checkout' [--detach] <commit>::
Prepare to work on top of <commit>, by detaching HEAD at it
(see "DETACHED HEAD" section), and updating the index and the
tree will be the state recorded in the commit plus the local
modifications.
+
-Passing `--detach` forces this behavior in the case of a <branch> (without
-the option, giving a branch name to the command would check out the branch,
-instead of detaching HEAD at it), or the current commit,
-if no <branch> is specified.
+When the <commit> argument is a branch name, the `--detach` option can
+be used to detach HEAD at the tip of the branch (`git checkout
+<branch>` would check out that branch without detaching HEAD).
++
+Omitting <branch> detaches HEAD at the tip of the current branch.
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
"--track" in linkgit:git-branch[1] for details.
+
If no '-b' option is given, the name of the new branch will be
-derived from the remote-tracking branch. If "remotes/" or "refs/remotes/"
-is prefixed it is stripped away, and then the part up to the
-next slash (which would be the nickname of the remote) is removed.
+derived from the remote-tracking branch, by looking at the local part of
+the refspec configured for the corresponding remote, and then stripping
+the initial part up to the "*".
This would tell us to use "hack" as the local branch when branching
off of "origin/hack" (or "remotes/origin/hack", or even
"refs/remotes/origin/hack"). If the given name has no slash, or the above
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by copying them from elsewhere, extracting a tarball, etc.
+--ignore-skip-worktree-bits::
+ In sparse checkout mode, `git checkout -- <paths>` would
+ update only entries matched by <paths> and sparse patterns
+ in $GIT_DIR/info/sparse-checkout. This option ignores
+ the sparse patterns and adds back any files in <paths>.
+
-m::
--merge::
When switching branches,
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
-As a special case, the `"@{-N}"` syntax for the N-th last branch
-checks out the branch (instead of detaching). You may also specify
+As a special case, the `"@{-N}"` syntax for the N-th last branch/commit
+checks out branches (instead of detaching). You may also specify
`-` which is synonymous with `"@{-1}"`.
+
As a further special case, you may use `"A...B"` as a shortcut for the
tag 'v2.0' (refers to commit 'b')
------------
-In fact, we can perform all the normal git operations. But, let's look
+In fact, we can perform all the normal Git operations. But, let's look
at what happens when we then checkout master:
------------
It is important to realize that at this point nothing refers to commit
'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted
-by the routine git garbage collection process, unless we create a reference
+by the routine Git garbage collection process, unless we create a reference
before that happens. If we have not yet moved away from commit 'f',
any of these will create a reference to it: