名称NAME
git-checkout - 切换分支或还原工作树文件
概要SYNOPSIS
git checkout [-q] [-f] [-m] [<branch>]
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>] [--] <pathspec>…
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…]描述DESCRIPTION
更新工作树中的文件以匹配索引或指定树中的版本。 如果未给出路径说明，则git checkout还将更新HEAD以将指定的分支设置为当前分支。
git checkout [<branch>]
要准备在<branch>上工作，请通过更新工作树中的索引和文件并将HEAD指向分支来切换到该分支。 保留对工作树中文件的本地修改，以便可以将它们提交到该<branch>。
如果未找到<branch>，但恰好在远程（称为<remote>）中存在一个匹配名称,并且未指定--no-guess的跟踪分支，则等同于
$ git checkout -b <branch> --track <remote>/<branch>您可以省略<branch>，在这种情况下，该命令会退化为“签出当前分支”，这是一个荣耀的无操作，具有相当昂贵的副作用，仅显示当前分支的跟踪信息（如果存在）。
git checkout -b|-B <new_branch> [<start point>]
指定 -b 会导致创建新分支，就像调用git-branch [1]然后将其检出一样。 在这种情况下，您可以使用--track或--no-track选项，这些选项将传递给git branch。 为方便起见，--track不带-b表示创建分支; 请参阅下面的--track的描述。
如果给定-B，则创建<new_branch>（如果不存在）; 否则，将被重置。这事务等效与
$ git branch -f <branch> [<start point>]
$ git checkout <branch>
也就是说，除非“ git checkout”成功，否则不会重置/创建分支。
git checkout --detach [<branch>]
git checkout [--detach] <commit>
准备在<commit>上工作，方法是分离HEAD（请参阅“DETACHED HEAD”部分），并更新工作树中的索引和文件。 保留对工作树中文件的本地修改，以便最终的工作树将是提交中记录的状态加上本地修改。
当 <commit>参数是分支名称时， --detach选项可用于在分支尖端分离 HEAD （git checkout <branch>将在不分离HEAD的情况下签出该分支）。
省略<branch>会在当前分支的顶端分离HEAD。
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]
覆盖与pathspec匹配的文件的内容。 如果未给出<tree-ish>（通常是一次提交），请使用索引中的内容覆盖工作树。 给出<tree-ish>后，用<tree-ish>中的内容覆盖索引和工作树。
由于先前的合并失败，索引可能包含未合并的条目。 默认情况下，如果你尝试从索引中签出这样的条目，则签出操作将失败并且将不检出任何内容。 使用-f将忽略这些未合并的条目。 可以通过使用--ours 或者--theirs来从特定的合并方面签出索引内容。 使用-m，可以放弃对工作树文件的更改以重新创建原始的冲突合并结果。
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…]
这与以前的模式相似，但是允许您使用交互式界面显示“ diff”输出并选择要在结果中使用的块。 有关--patch选项的说明，请参见下文。
OPTIONS
-q --quiet
Quiet, suppress feedback messages.
--progress
--no-progress
除非指定了--quiet，否则默认情况下，将进度状态报告给标准错误流时将其报告到终端上。 即使未连接到终端，此标志也可以启用进度报告，而不管--quiet。
-f --force
切换分支时，即使索引或工作树与HEAD不同，也要继续进行。 这用于丢弃本地更改。
从索引中签出路径时，不要在未合并的条目上失败； 相反，未合并的条目将被忽略。
--ours
--theirs
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 and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirsgives the version from the branch that holds your work that is being rebased.
This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours(i.e. "our shared canonical history"), while what you did on your side branch as theirs (i.e. "one contributor’s work on top of it").
-b <new_branch>
创建一个名为<new_branch> 的新分支，并在<start_point>开始; 有关详细信息，请参见git-branch [1]。
-B <new_branch>
创建分支 <new_branch>并从 <start_point>开始; 如果已经存在，则将其重置为<start_point>。
This is equivalent to running "git branch" with "-f"; see git-branch[1] for details.
-t --track
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 be 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 guessing results in an empty name, the guessing is aborted. You can explicitly give a name with -b in such a case.
--no-track
Do not set up "upstream" configuration, even if the branch.autoSetupMerge configuration variable is true.
--guess
--no-guess
如果未找到<branch>，但恰好在远程（称为<remote>）存在一个匹配名称跟踪分支，则等同于
$ git checkout -b <branch> --track <remote>/<branch>如果分支存在于多个远程站点中，并且其中一个分支由checkout.defaultRemote配置变量命名，则出于歧义的目的，即使 <branch>在所有远程站点中并非唯一，我们仍将使用该分支。
例如将其设置为 checkout.defaultRemote=origin ，如果<branch>模棱两可但在远程源上存在，则总是从那里检出远程分支。
使用--no-guess禁用此功能
-l
创建新分支的引用日志。 see git-branch[1] for details.
--detach（分离）
不是签出分支来进行工作，而是签出一个提交用来进行检查和做可丢弃的实验尝试。 当<commit>不是分支名称时，这是git checkout <commit>的默认行为。 See the "DETACHED HEAD" section below for details.
--orphan <new_branch>
Create a new orphan branch, named <new_branch>, started from <start_point> and switch to it. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.
The index and the working tree are adjusted as if you had previously run git checkout <start_point>. This allows you to start a new history that records a set of paths similar to <start_point> by easily running git commit -a to make the root commit.
This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is "clean", but whose full history contains proprietary or otherwise encumbered bits of code.
If you want to start a disconnected history that records a set of paths that is totally different from the one of <start_point>, then you should clear the index and the working tree right after creating the orphan branch by running git rm -rf . from the top level of the working tree. 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
切换分支时，如果你对一个或多个文件的本地修改在当前分支和要切换到的分支之间不同，则该命令将拒绝切换分支以保留上下文中的修改。 但是，使用此选项，将在当前分支，工作树内容和新分支之间进行三向合并，并且你将位于新分支上。
发生合并冲突时，冲突路径的索引条目将保持未合并状态，你需要解决冲突并使用git add标记已解决的路径（或者，如果合并会导致路径的删除，可以使用git rm）。
从索引中检出路径时，此选项可让您在指定的路径中重新创建冲突的合并。
当使用--merge切换分支时，暂存的更改可能会丢失。
--conflict=<style>
The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the merge.conflictStyle configuration variable. Possible values are "merge" (default) and "diff3" (in addition to what is shown by "merge" style, shows the original contents).
-p --patch
Interactively select hunks in the difference between the <tree-ish> (or the index, if unspecified) and the working tree. The chosen hunks are then applied in reverse to the working tree (and if a <tree-ish> was specified, the index).
This means that you can use git checkout -p to selectively discard edits from your current working tree. See the “Interactive Mode” section of git-add[1] to learn how to operate the --patchmode.
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 by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree.
--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 will fail unless -f is used. If nothing (or --no-recurse-submodules) is used, the work trees of submodules will not be updated. Just like git-submodule[1], this will detach HEAD of the submodule.
--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.
--pathspec-from-file=<file>
Pathspec is passed in <file> instead of commandline args. If <file> is exactly - then standard input is used. Pathspec elements are separated by LF or CR/LF. Pathspec elements can be quoted as explained for the configuration variable core.quotePath (see git-config[1]). See also --pathspec-file-nul and global --literal-pathspecs.
--pathspec-file-nul
Only meaningful with --pathspec-from-file. Pathspec elements are separated with NUL character and all other characters are taken literally (including newlines and quotes).
<branch>
签出的分支； 如果它指向一个分支（即名称，当以"refs/heads/"开头时是有效的引用），则将该分支检出。 否则，如果它指的是有效的提交，则您的HEAD将变为"分离''并且您不再位于任何分支上（详细信息请参见下文）。
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}.
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 leave out at most one of A and B, in which case it defaults to HEAD.
<new_branch>
新分支的名称。
<start_point>
开始新分支的提交的名称； 有关详细信息，请参见git-branch [1]。 默认为HEAD。
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 leave out at most one of A and B, in which case it defaults to HEAD.
<tree-ish>
Tree to checkout from (when paths are given). If not specified, the index will be used.
--
不要将其他参数解释为选项。
<pathspec>…
限制受操作影响的路径。
