为什么带路径的Git签出不影响在Pro git中声明的索引？

Question

我正在学习Pro以了解reset和checkout是如何工作的。我现在了解了这些树，以及每个命令是如何影响每个树的，这取决于模式和是否指定了路径。但有一件事让我很困惑。

Pro Git指定在将git checkout与路径一起使用时：

git签出就像git重置分支文件一样，因为它在提交时用该文件更新索引，但它也会覆盖工作目录中的文件。“

然而，在我的实验中，我无法再现这种预期的行为。

如果我在主题分支上提交red，green，blue

9c070df (HEAD -> colors) blue
28a97c1 green
5edafd9 red

使用一个文件，其修补程序是：

9c070df (HEAD -> colors) blue
diff --git a/colors.txt b/colors.txt
index 9d8beb6..ff67b54 100644
--- a/colors.txt
+++ b/colors.txt
@@ -1,2 +1,3 @@
 red
 green
+blue
28a97c1 green
diff --git a/colors.txt b/colors.txt
index a9d1386..9d8beb6 100644
--- a/colors.txt
+++ b/colors.txt
@@ -1 +1,2 @@
 red
+green
5edafd9 red
diff --git a/colors.txt b/colors.txt
new file mode 100644
index 0000000..a9d1386
--- /dev/null
+++ b/colors.txt
@@ -0,0 +1 @@
+red

如果HEAD是蓝色的，而我是git reset 5edafd9 -- colors.txt，我会

+ green
+ blue

在工作树上

- green
- blue

在索引中，这是预期的，因为只有行red应用于索引。因此，当工作树与索引不同时，看起来像添加了这些行，当索引与头不同时，这些行看起来就被删除了。这是预料中的，也是可以理解的。

但是，当我git checkout -- colors.txt时，只有工作树会受到影响，使索引保持不变。

为什么会这样呢？

Answer 1

但是，当我git checkout -- colors.txt时，只有工作树会受到影响，使索引保持不变。

这是因为这种形式的签出(git checkout [] [--] …​)是通过替换索引或<tree-ish>中的内容(通常是提交)来覆盖工作树中的路径。

对于Git 2.23，这将是git restore将做的事情：

默认情况下，'git restore‘只更新工作树。(与“checkout <tree> <paths>”不同，后者更新工作树和索引，就像git restore --staged --worktree --source一样)。

如果您想切换分支，您将使用git switch。

Git 2.23将在几天内发布，2019年8月。

Answer 2

git checkout命令是..。复杂:-)

• git checkout -- colors.txt将colors.txt从索引(:colors.txt)复制到工作树。(这就是你所做的。)
• git checkout HEAD -- colors.txt将colors从头提交(HEAD:colors.txt)复制到索引，然后复制到工作树。(这就是你的本意。)

在这两种情况下，这都可能覆盖未提交的数据:在索引到工作树的情况下，它将覆盖任何工作树版本，这些工作树版本被git status称为“为了提交而不分阶段”，而在头对索引和工作树的情况下，它也将覆盖git status将称为“为提交而分阶段”的任何索引版本。

当然，与此同时：

• git checkout branchname切换到给定的分支名称，同时也将文件从该分支的提示提交到索引和工作树--但是这个特定的git checkout操作是无损的，如果它必须覆盖未提交的数据，就会失败。
• 非分支名称的提交说明符的git checkout将在给定提交时切换到分离的头部，这也是非破坏性的。

(这可能会迫使它们具有破坏性。)

• 使用-m标志，git checkout将重建冲突的合并(破坏性的)或尝试合并一个或多个文件(可能具有一定的破坏性)。
• 使用--ours或--theirs，git checkout可以提取文件的索引暂存版本2或3。这对任何未保存的工作树数据都具有破坏性。

这些选项(在-m中与路径规范一起使用时)在某些方面与前两种情况有些相似:当前的分支不会改变；只有工作树，也许还有文件的索引副本会改变。

• 使用-b、-t / --track或--no-track，git checkout可以创建一个新分支。使用-B，git checkout可以创建一个新分支，或者实际上可以创建一个现有分支。使用--orphan，git checkout可以在类似于新的、完全空的存储库中的情况下设置您，在这种情况下，您进行的下一次提交将创建一个没有以前提交的分支。

这些操作有点像第二组git checkout行为，因为如果git checkout成功的话，您可能在不同的分支上。这些通常也是无损的。但是，请注意，-B可以任意移动现有的分支名称。如果没有启用reflogs，这可能很难恢复。

• 使用-p，git checkout可以交互地修补提交(如Git所说的任何“树形”)与工作树、索引和工作树之间的差异。

您还可以在混合中添加几个选项，但这五组非常不同的行为都被放入一个git checkout命令中。我一直认为这太拥挤了，到了Git 2.23，Git的人似乎终于同意了: Git将有两个新的命令，git switch和git restore，它们只做了git checkout目前所做的一些工作。git checkout仍然存在，并且仍然按其一贯的方式运行，但是如果您想从master切换到develop，您可以运行git switch develop，而不必担心如果输入错误develop会发生什么。(目前，如果您将其错误地键入为git checkout devop，则可能会对未提交的名为devop的文件进行重击。)