当存储一些更改时，Git 会创建两个单独的提交，“分支上的 WIP”和“分支上的索引”：
$ git log --graph --all
* commit 98aac13303ca086580c1ec9ccba5fe26c2a8ef3c
|\ Merge: 7d99786 82c5c76
| | Author: Tieme <[email protected] /cdn-cgi/l/email-protection>
| | Date: Wed Nov 19 09:58:35 2014 +0100
| |
| | WIP on development: 7d99786 Last real commit
| |
| * commit 82c5c763357c401135675a39bfabf9b7f6805815
|/ Author: Tieme <[email protected] /cdn-cgi/l/email-protection>
| Date: Wed Nov 19 09:58:35 2014 +0100
|
| index on development: 7d99786 Last real commit
|
|
| * commit 7d9978637a0e1ef92f2432189bdebf2317f0b2f0
| Author: Tieme <[email protected] /cdn-cgi/l/email-protection>
| Date: Tue Nov 18 17:32:33 2014 +0100
|
| Last real commit
|
我查了一下文档 https://www.kernel.org/pub/software/scm/git/docs/git-stash.html为此，但它并没有使它更清楚：
存储表示为提交，其树记录了工作目录的状态，其第一个父级是创建存储时位于 HEAD 的提交。第二个父级的树记录了存储时索引的状态，并且它成为 HEAD 提交的子级。祖先图如下所示：
.----W
/ /
-----H----I
其中H是HEAD提交，I是记录索引状态的提交，W是记录工作树状态的提交。
为什么我更改的文件创建了 2 个提交，而不只是一个？
简短回答
git stash区分索引上的更改和工作树中的更改，并为它们创建提交。
长答案
一些背景
使用 git，工作树（直接使用的文件）中的更改可能与索引上的更改不同。
仅将有限数量的文件添加到索引，或者使用git add --patch即使在文件中添加单个更改行也会使索引处于与工作树不同的状态。
这是一件好事，因为它使您能够创建专注于某个特定任务/功能的提交。
甚至有可能您对索引进行了更改，而这些更改不再是工作树的一部分。您可以通过向索引添加一些更改来测试它（git add），手动从文件中删除它们，然后创建一个提交（git commit).
提交仍将包含您首先添加的更改，尽管它们不再存在于您的工作树中。
如果您无法理解工作树和索引之间的区别，您可以看看这个问题 https://stackoverflow.com/questions/3689838/difference-between-head-working-tree-index-in-git.
究竟发生了什么？
现在，一开始的说法应该更有意义了。一个“存储提交”包含您在工作树（您直接使用的文件）中所做的所有更改，另一个包含您添加到索引中的更改。
默认情况下git stash pop or git stash apply只尝试恢复您在工作树中所做的更改，并忽略您对索引所做的更改。
可以说git stash也尝试使用以下命令恢复索引--index flag (git stash (pop|apply) --index).
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
