git checkout简介

待我称王封你为后i 2022-05-23 07:58 139阅读 0赞

# git-checkout手册页 #

## 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>] [--] <paths> ...

git checkout [-P | --patch] [ <tree-ish>] [--] [<paths> ...]

## DESCRIPTION描述 ##

更新工作树中的文件以匹配索引或指定树中的版本。如果没有给出路径，那么*git checkout*也会更新`HEAD`以将指定的分支设置为当前分支。

***git checkout***** <branch>**

要准备在<branch>上工作，通过更新工作树中的索引和文件并将HEAD指向分支来切换到它。对工作树中的文件进行本地修改保留，以便它们可以被提交给<分支>。

如果找不到<branch>，但确实在一个远程（具有匹配的名称称为<remote>）中存在跟踪分支，则视为等同于

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

您可以省略<branch>，在这种情况下，该命令退化为“检出当前分支”，这是一个相当昂贵的副作用，如果存在，仅显示当前分支的跟踪信息。

***git checkout***** -b| -B <new\_branch> \[<start point>\]**

指定`-b`会导致创建新分支，就像 调用git-branch（1）然后检出一样。在这种情况下，你可以使用`--track`或`--no-track`选项，它将被传递给*git分支*。作为一种方便， `--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）。

省略<分支>在当前分支的顶端分离HEAD。

***git checkout***** \[-p| --patch\] \[<tree-ish>\] \[ - \] <pathspec> ...**

当<路径>或`--patch`给出，*git checkout不会*切换分支。它从索引文件或命名的<tree-ish>（通常是提交）更新工作树中的命名路径。在这种情况下，`-b`和`--track`选项是没有意义的，并给出其中任何一个都会导致错误。在更新工作树之前，可以使用<tree-ish>参数来指定特定的tree-ish（即commit，tag或tree）来更新给定路径的索引。

使用<paths>的*git checkout*或`--patch`用于从索引中恢复其修改或删除的原始内容的路径，或用来自名为<tree-ish>（通常是commit-ish）的内容替换路径。

由于先前的合并失败，索引可能包含未合并的条目。默认情况下，如果您试图从索引中检出这样的条目，则检出操作将失败并且不会检出任何内容。使用`-f`将忽略这些未合并的条目。通过使用`--ours`或，可以从索引中检出合并的特定方的内容`--theirs`。使用时`-m`，可以放弃对工作树文件所做的更改，以重新创建原始冲突的合并结果。

## OPTIONS选项 ##

**-q**

**- quiet**

安静，抑制反馈信息。

**-F**

**- force**

切换分支时，即使索引或工作树与HEAD不同，也要继续。这用于丢弃本地更改。

从索引检出路径时，请勿在未合并的条目上失败; 相反，未合并的条目将被忽略。

**--ours**

**--theirs**

当从索引中检出路径时，请检查第2阶段（*我们的*）或第3阶段（*他们的*）是否有未合并的路径。

请注意，在`git rebase`和期间`git pull --rebase`，*我们*和 *他们的人*可能会出现交换; `--ours`给出了分支版本的变更重新分配到`--theirs`的版本，同时给出了分支中保存正在重新分配工作的版本。

这是因为`rebase`在将远程历史记录视为共享规范的工作流中使用，并将待分配的分支上的工作作为要整合的第三方工作来处理，并且您暂时承担亚历山大期间经典历史的守护者。作为规范历史的守护者，您需要从远程查看历史记录`ours`（即“我们共享的规范历史”），而您在您的支行上做了什么`theirs`（即“一个贡献者在其之上的工作”）。

**-b <new\_branch>**

创建一个名为<new\_branch>的新分支并在<start\_point>处启动它; 有关详细信息，请参阅git-branch（1）。

**-B <new\_branch>**

创建分支<new\_branch>并在<start\_point>处启动它; 如果它已经存在，则将其重置为<start\_point>。这相当于用“-f”运行“git branch”; 有关详细信息，请参阅 git-branch（1）。

**-t**

**- track跟踪**

创建新分支时，设置“上游”配置。有关详细信息，请参阅git-branch（1）中的“--track” 。

如果未给出*-b*选项，则通过查看为相应远程配置的refspec的本地部分，从远程跟踪分支派生新分支的名称，然后剥离最初的部分直到“\* ”。这将告诉我们在分支“origin/ hack”（或“远程/源/黑客”，甚至“refs / remotes / origin / hack”）时使用“hack”作为本地分支。如果给定名称没有斜线，或者上述猜测结果为空名称，则猜测会中止。你可以明确地给出一个名字*-b*在这种情况下。

**--no-trace**

即使branch.autoSetupMerge配置变量为true，也不要设置“上游”配置。

**-l**

创建新分支的reflog; 有关详细信息，请参阅git-branch（1）。

**- detach（分离）**

而不是检查一个分支来处理它，检查提交检查和可废弃的实验。当<commit>不是分支名称时，这是“gitcheckout <commit>”的默认行为。有关详细信息，请参阅下面的“分离头部”一节。

**--orp <new\_branch>**

创建一个名为<new\_branch> 的新*孤立*分支，从<start\_point>开始并切换到该分支。在这个新分支上进行的第一次提交将没有父母，它将成为与所有其他分支和提交完全断开连接的新历史记录的根。

索引和工作树被调整，就像您以前运行过“git checkout <start\_point>”一样。这允许您通过轻松运行“git commit -a”来启动一个新的历史记录来记录一组类似<start\_point>的路径，以便进行根提交。

如果您想从提交中发布树而不公开完整的历史记录，这会很有用。您可能想要这样做来发布项目的开源分支，该分支的当前树是“干净的”，但其完整历史记录包含专有或其他设计的代码位。

如果你想开始一个断开连接的历史记录，记录一组完全不同于<start\_point>的路径，那么你应该在创建孤立分支后通过运行“git rm -rf”清除索引和工作树。 “ 来自工作树的顶层。之后，您将准备好准备新文件，重新填充工作树，从别处复制它们，提取tarball等。

**- ignore-skip-worktree-bits**

在稀疏结帐模式下，`git checkout -- <paths>`只会更新$ GIT\_DIR / info / sparse-checkout中由<路径>和稀疏模式匹配的条目。此选项会忽略稀疏模式并添加<paths>中的任何文件。

**-m**

**- merge(合并)**

在切换分支时，如果对当前分支与切换到的分支之间的一个或多个文件进行本地修改，则该命令将拒绝切换分支以便在上下文中保留修改。但是，使用此选项，当前分支，工作树内容和新分支之间的三向合并已完成，并且您将位于新分支上。

当合并冲突发生时，冲突路径的索引条目未被合并，您需要解决冲突并标记已解析的路径`gitadd`（或`gitrm`合并是否应导致删除路径）。

当从索引检出路径时，使用此选项可以在指定的路径中重新创建冲突的合并。

**--conflict = <style>**

与上面的--merge选项相同，但改变了冲突的区块显示方式，覆盖merge.conflictStyle配置变量。可能的值是“合并”（默认）和“diff3”（除了“合并”样式显示的内容，显示原始内容）。

**-p**

**- patch（补丁）**

在<tree-ish>（或索引，如果未指定）和工作树之间的区别中交互地选择hunk。然后将选定的区块反向应用于工作树（并且如果指定了<tree-ish>，则索引）。

这意味着您可以使用`git checkout -p`有选择地放弃当前工作树中的编辑。请参阅git-add（1）的“交互模式”部分，了解如何操作该`--patch`模式。

**- ignore-other-worktrees**

`git checkout`当被通缉的裁判已经被另一个工作树签出时拒绝。这个选项使它无论如何检查裁判。换句话说，裁判可以由多个工作树持有。

**<branch>**

分行结账; 如果它引用了一个分支（即，前缀为“refs / heads /”的名称是有效的ref），那么该分支将被签出。否则，如果它指向一个有效的提交，那么您的HEAD变为“分离”，并且您不再在任何分支上（详情见下文）。

作为特例，第`"@{-N}"`N个分支/提交的语法检出分支（而不是分离）。你也可以指定 `-`哪一个是同义词`"@{-1}"`。

作为更进一步的特例，如果只有一个合并基础，则可以将其`"A...B"`用作合并基础的快捷方式。你可以在大多数的一个离开了和，在这种情况下默认为。`ABABHEAD`

**<new\_branch>**

新分支的名称。

**<start\_point>**

要开始新分支的提交的名称; 有关详细信息，请参阅 git-branch（1）。默认为HEAD。

**<tree-ish>**

要检出的树（当有路径时）。如果未指定，则会使用索引。

## DETACHED HEAD已拆卸的头部 ##

HEAD通常指的是一个命名分支（例如*master*）。同时，每个分支都涉及特定的提交。让我们看看一个有三个提交的回购，其中一个被标记，并且检出分支*主机*：

![20180605110823427][]

在此状态下创建提交时，分支会更新以引用新的提交。具体来说，*git commit*创建一个新的提交*d*，其父提交*c*，然后更新分支*主机*以引用新的提交*d*。HEAD仍然指分支*主机*，因此间接指现在提交*d*：

![20180605110856848][]

能够检出不在任何命名分支顶端的提交，或者甚至创建未由命名分支引用的新提交，有时很有用。让我们看看checkout提交*b*时会发生什么（这里我们展示两种可能的方式）：

![20180605110929316][]

请注意，无论我们使用哪个checkout命令，HEAD现在直接指向提交*b*。这被称为处于分离HEAD状态。这意味着HEAD指的是一个特定的提交，而不是指向一个已命名的分支。我们来看看创建提交时会发生什么：

![20180605111001891][]

现在有一个新的提交*e*，但它仅由HEAD引用。我们当然可以在这个状态下添加另一个提交：

![20180605111038188][]

事实上，我们可以执行所有正常的Git操作。但是，让我们看看当我们结账主人时会发生什么：

![20180605111112845][]

认识到这一点很重要，在这一点上没有任何提到 *f*。最终提交*f*（并通过扩展提交*e*）将被例程Git垃圾回收进程删除，除非我们在此之前创建了引用。如果我们还没有从提交*f中*移除，其中任何一个都会创建一个对它的引用：

$ git checkout -b foo    （1）

$ git branch foo         （2）

$ git tag foo            （3）

1.      创建一个新的分支*foo*，它指向提交*f*，然后更新HEAD以引用分支*foo*。换句话说，在这个命令之后，我们将不再处于分离的HEAD状态。

2.      类似地创建一个新的分支*foo*，它指向提交*f*，但是将HEAD分离。

3.      创建一个新的标签*foo*，它引用提交*f*，使HEAD脱离。

如果我们已经离开了commit *f*，那么我们必须首先恢复它的对象名（通常使用git reflog），然后我们可以创建一个对它的引用。例如，要查看HEAD引用的最后两个提交，我们可以使用以下任一命令：

$ git reflog -2 HEAD＃或

$ git log -g -2 HEAD

## EXAMPLES例子 ##

###### 一.      以下序列检出`master`分支，将其恢复`Makefile`为两个修订版，错误地删除hello.c，并从索引中取回它。 ######

2. $ git checkout master              （1）

3. $ git checkout master〜2 Makefile   （2）

4. $ rm -f hello.c

$ git checkout hello.c             （3）

1.开关分支

2.从另一个提交中取出一个文件

3.从索引恢复hello.c

如果你想从索引中检出*所有的* C源文件，你可以这样说

$ git checkout  - '* .c'

注意周围的引号`*.c`。`hello.c`即使该文件不在工作树中，该文件也将被检出，因为文件通配符用于匹配索引中的条目（不在shell的工作树中）。

如果你有一个不幸的分支被命名`hello.c`，这个步骤将被混淆为一条指令切换到该分支。你应该写：

$ git checkout  -  hello.c

###### 二.     在错误的分支中工作之后，切换到正确的分支将使用以下命令完成： ######

$ git checkout mytopic

但是，您在本地修改的文件中，您的“错误”分支和正确的“mytopic”分支可能有所不同，在这种情况下，上述结帐将失败，如下所示：

$ git checkout mytopic

错误：您对“frotz”进行了本地更改; 不切换分支。

您可以将该`-m`标志赋予该命令，该命令将尝试三路合并：

$ git checkout -m mytopic

自动合并frotz

在这种三路合并之后，本地修改*没有* 在您的索引文件中注册，因此`git diff`会显示您自从新分支的提示以来所做的更改。

###### 三.      在使用该`-m`选项切换分支期间发生合并冲突时，您会看到如下所示的内容： ######

$ git checkout -m mytopic

Auto-merging frotz     (自动合并frotz)

ERROR:Merge conflict in frotz     (错误：在frotz中合并冲突)

fatal:merge program failed    (致命：合并程序失败)

此时，`git diff`显示如前例所示的整合合并以及冲突文件中的更改。编辑并解决冲突并`gitadd`像往常一样将其标记为已解决 ：

$ edit frotz

$ git add frotz

最后更新时间2015-10-19 19:46:04协调世界时

[20180605110823427]: /images/20220523/e8932488035342d1bb331e0147b894e5.png
[20180605110856848]: /images/20220523/987600dbc43b4576b8a914ccd8f45482.png
[20180605110929316]: /images/20220523/2b4196b54a2f4b71a7052a97e4557ce3.png
[20180605111001891]: /images/20220523/ca8c5e9ad48e40b4a551dac3983e3480.png
[20180605111038188]: /images/20220523/b04839dad9b647bd91c8917d3c684aaa.png
[20180605111112845]: /images/20220523/cbd3791070e44191aabe542a247b873b.png