为什么 git stash 创建 2 个提交对象？好像1就够了答案

【问题标题】：Why does git stash creates 2 commit objects? Seems like 1 was adequate为什么 git stash 创建 2 个提交对象？好像1就够了
【发布时间】：2017-05-17 09:26:06
【问题描述】：

在执行git stash 时，会创建 2 个提交。一个由 stash ref 引用，并且有 2 个父提交。一个父母是我们藏匿地点的索引。另一个父母拥有我们隐藏的实际内容。
为什么存储需要 2 次提交？在我看来，只有 1 就足够了。 IE。只需将 stash 引用到具有实际内容的提交即可。
这不行吗？

【问题讨论】：

标签： git git-commit git-stash

【解决方案1】：

git stash 实际上，最多会进行三个次提交。您观察到的两个是默认的两个：一个用于 index 状态 - 请记住，在 Git 中，索引，也称为 staging area，包含 下一个 提交写入，并在您每次git add 新内容时更新——其中一个用于 work-tree 状态。这些可能彼此不同和/或与您创建存储时的HEAD 提交不同。

根本问题是git stash 不仅仅意味着保存您当前的工作树，也不仅仅是保存您当前的索引状态，也不仅仅是保存两者的某种组合。如果您打算保存当前的索引状态，您可以简单地进行普通提交。如果您打算保存两者的组合，您可以简单地运行git commit -a。

相反，git stash 默认分别保存索引状态和工作树状态。这允许您稍后再次检索这两个单独的状态，if 这就是您的意思。它允许您检索两种状态的混合版本，if 这就是您的意思。而且，如果您使用-u 或-a，那么git stash 的第三次提交包含未跟踪或未跟踪和忽略的文件，它允许您恢复所有这些不同的状态。

您不是在保存存储时表达您的最终意图，而是在您恢复它时。¹这可能不是最好的设计，因为 (a) 有时无法恢复您的预期状态，以及 (b) 如果您使用 git stash pop 而没有 --index 当您有打算使用 @987654333 @，这会破坏分离的状态，然后丢弃两个提交，使其极难恢复。不过，总的来说，推迟决策通常是一种好方法。

¹如果您在保存存储时使用--keep-index，实际上您在保存时至少声明了一些意图。但这完全是另一回事。此外，git stash 中存在一个长期存在的错误，这使得保持索引和工作树状态分开存在问题。详情请见here。

【讨论】：

我没有看到 3 个提交。我只看到 2 个提交。如果我在提交 A 时确实在 master 上进行了 stash 保存，我看到 ref/stash 指向 C ，它的父母 A 和 B 和 B 是一个松散的对象，其中包含我在提交时提交的内容味精：index on master: A。从这 3 个来看，在我看来 C 是多余的，而 ref/stash 也可以指向 B。我没明白你的意思吗？
查看第三段：只有-u 或-a 才能获得第三次提交。确实，如果索引或工作树提交相互匹配，或者其中一个与存储袋悬挂的提交匹配，那么其中一个提交是多余的——但关键是stash 脚本保存了两者, 故意的，以防您打算稍后单独恢复它们。尝试git add-ing 一些更改，然后再次修改同一个文件，然后存储 - 或使用 git add -p 仅添加一些更改的文件的部分，然后存储。
@Jim：我稍微扩展了第一段（现在我看到我应该修剪第三段 :-) 以匹配）。