为什么存储表示为 2 次提交？

Question

当存储一些更改时，Git 会创建两个单独的提交，“WIP on branch”和“index on branch”：

$ git log --graph --all 

*   commit 98aac13303ca086580c1ec9ccba5fe26c2a8ef3c
|\  Merge: 7d99786 82c5c76
| | Author: Tieme <my@email.com>
| | Date:   Wed Nov 19 09:58:35 2014 +0100
| |
| |     WIP on development: 7d99786 Last real commit
| |
| * commit 82c5c763357c401135675a39bfabf9b7f6805815
|/  Author: Tieme <my@email.com>
|   Date:   Wed Nov 19 09:58:35 2014 +0100
|
|       index on development: 7d99786 Last real commit
|
|
| * commit 7d9978637a0e1ef92f2432189bdebf2317f0b2f0
| Author: Tieme <my@email.com>
| Date:   Tue Nov 18 17:32:33 2014 +0100
|
|     Last real commit
|

我为此查找了documentation，但它并没有使它更清楚：

一个 stash 表示为一个提交，其树记录了工作目录的状态，并且它的第一个父级是创建 stash 时在 HEAD 处的提交。第二个父级的树记录了存储时索引的状态，并使其成为 HEAD 提交的子级。祖先图如下所示：

         .----W
        /    /
  -----H----I

其中 H 是 HEAD 提交，I 是记录索引状态的提交，W 是记录工作树状态的提交。

为什么我更改的文件创建了 2 个提交，而不仅仅是一个提交？

Answer 1

简答

git stash 区分索引上的更改和工作树中的更改，并为它们创建提交。

长答案

一些背景

使用 git，您在工作树中所做的更改（您直接使用的文件）可能与您在索引上所做的更改不同。

仅将有限数量的文件添加到索引中，或者使用git add --patch，即使在文件中添加单个更改的行，也会使您的索引处于与工作树不同的状态。
这是一件好事，因为它使您能够创建专注于一个特定任务/功能的提交。

您的索引甚至有可能不再属于您的工作树的一部分。您可以通过向索引添加一些更改 (git add)、手动从文件中删除它们然后创建提交 (git commit) 来测试它。
提交仍将包含您最初添加的更改，尽管它们不再存在于您的工作树中。

如果您无法理解工作树和索引之间的区别，可以查看this question。

到底发生了什么？

现在从一开始的陈述应该更有意义。一个“存储提交”包含您在工作树中所做的所有更改（您直接使用的文件），另一个包含您添加到索引中的更改。

默认情况下git stash pop 或git stash apply 只会尝试恢复您在工作树中所做的更改，而忽略您对索引所做的更改。 也可以使用 --index 标志 (git stash (pop|apply) --index) 告诉 git stash 尝试恢复您的索引。