git stash应用仅恢复未暂存的文件

 LeGEC已经回答您需要使用git stash apply --index。原因如下。

我在分支A上更改了大约24个文件。这些文件都没有提交。其中一些有更改的文件，比如说18个是未暂存的。其他6个文件被暂存。

值得指出的是：staged只是意味着在Git的索引中更新。

让我们再细分一下。Git提交有两个部分：

• 任何给定Git提交的一部分都是元数据：关于提交的信息，比如谁提交了，什么时候提交等等。这非常有用，但现在对你来说并不重要。

• 提交的另一部分是每个文件的保存快照，与您(或任何人)提交时的形式相同。

整个提交都是只读的：任何现有提交的任何部分都不能更改。此外，提交中内存储的文件是一种特殊的压缩和消除重复的Git格式，只有Git才能读取。因此，这些文件不仅不可能更改，而且您计算机上的大多数程序都不可能以任何方式使用。这意味着，在使用提交之前，必须让Git提取存档文件。

这种提取(主要)就是git checkout或git switch的意义：你告诉Git:删除我以前提取的所有文件，我对那些文件不再感兴趣。转到其他提交并提取其文件现在您有了文件，可以查看和使用，甚至更改。这些可用的、可工作的文件位于Git所称的工作树或

的工作树显然，如果所有文件都有源存档，那么每个文件都必须有两个副本：提交中的一个(存档且只能由Git读取，任何人都不能写入——按照Git存储的方式，它甚至可能不是一个文件)，加上工作树中的那个(以正常的日常形式：一个实际的文件)。但这里有个诀窍。存在第三"；复制"；每个文件的。这个额外的拷贝——或者"；"复制"；，在引号中--采用重复数据消除格式，但与提交中的副本不同，可以被替换。我们也应该称之为第二个副本：第一个副本在提交中，这是每个文件的的第二个副本。因为它已经消除了重复，所以最初只是重新使用提交的副本。因此，工作树中的普通文件是第三个副本，并且它总是副本，因为它不是只使用Git消除重复的格式。

第二个副本是Git的内部格式，但是可替换的，存在于Git所称的索引或暂存区中，或者——现在很少——缓存。(名称的最后一种形式主要显示为标志，例如git rm --cached或git diff --cached)。当您在工作树文件上使用git add时，Git:

• 将工作树文件副本压缩为Git的内部格式
• 检查是否重复；以及
• 将正确更新的副本(新文件或重复使用旧副本)放入Git的索引中

当您运行git commit时，Git实际上会从索引中的中生成提交快照这就是为什么您必须不断地git add文件你在告诉Git:替换索引副本这会将更新后的工作树副本复制到Git的索引中，准备提交。所以说6个文件是"；"阶段性"；真正的意思是：在下一次提交中的(比如说)400个文件中——现在在Git的索引中——394个与当前提交中的文件相同，6个与当前提交不同。

说24个文件是"；无标签"；意思是：在Git索引中的400个文件中，376个(400减去24)与我的工作树中的正常格式文件匹配，24个不匹配。

请注意，由于每个文件有三个副本，因此有可能同时有暂存的更改(文件file.ext的索引副本与提交的副本不同)和未暂存的更改(file.ext的工作树副本与待提交的索引副本不同)。这是因为阶段性更改只是意味着HEAD-与索引的差异：下一次提交的该文件副本将更新未分级的更改只是意味着索引与工作树的区别：可以git add此文件，这将用工作树副本替换索引副本(Git用于进入下一个)提交。

git stash的作用是：

• 保存文件的整个索引集，就像在提交中一样：事实上，它确实用它进行了提交，就像任何提交一样，只是新的提交不在任何分支上；那么
• 对于Git索引中存在的每个文件，git add是工作树文件，并从中提交结果，只是(再次)新的提交不在任何分支上；那么
• 运行git reset --hard

此序列有时会被您提供给git stash的选项更改，但这是主要序列：Git在无分支上进行两次提交，以保存索引和工作树状态，然后使用git reset --hard使索引和工作树与当前(HEAD)提交相匹配。

稍后，当您使用git stash apply恢复索引和/或工作树时，必须选择：

• 我只想应用工作树提交，完全忽略索引提交：这是git stash apply。或者：

• 我想同时应用工作树提交和索引提交：这是git stash apply --index。

所以Git总是同时保存，但在apply时，您必须选择是否使用保存的索引。默认为"；而不是"；。