实际上撤消git stash pop

Question

这个问题具有相同的标题,但它不是同一个问题.这个问题实际上是在问"放弃git stash pop的结果".实际上这个问题

UNDO git stash pop

换一种说法

// in branch foo
git stash
git checkout bar
git stash pop       # ERROR. I didn't want to pop on top of bar, lots of conflicts
git stash undo-pop  # NEED COMMAND TO PUT STASH AND LOCAL FILES BACK AS THEY WERE
git checkout foo
git stash pop

有没有办法让我在打字之前把所有东西都带回状态git stash pop？换句话说,实际上取消流行音乐并将藏匿的东西放回藏匿处并将本地文件放回到我输入git stash pop之前的状态.

这也不是如何在Git中恢复被丢弃的存储的愚蠢行为？ 虽然这在某些情况下可能会有所帮助

Answer 1

在您的示例中,要恢复到之前的状态git stash pop,请使用:

git reset --hard bar

这种形式的git reset命令将索引的状态和工作目录恢复到bar分支的头部.

因为第一个存在冲突git stash pop,所以存储仍然存在于存储堆栈的顶部.

从那里,你可以git checkout foo和git stash pop试.

Answer 2

Greg Hewgill 的答案是正确的（并且得到了赞成，OP 应该接受它）但是这里还有一些额外的警告，以防有人想以更通用的方式使用答案。我们先来看看具体使用的命令序列：

git stash
git checkout bar
git stash pop       # ERROR ... lots of conflicts

现在，让我们列出注意事项：

• 重要的是git stash pop失败了。（格雷格已经注意到这一点。）
• 您在创建 stash 时没有使用git stash --keep-index。
• 运行后git stash，您没有对工作树进行任何更改。
• 该git checkout命令成功，那么它可能已经修改了你的工作树，事实上，它必须这样做的pop失败，而是你的工作树仍是“干净”的，因为git status会说。

这是最后一点，它git status会（在尝试之前git stash pop）告诉您您的工作树是clean，这是关键。如果您对工作树进行了更改，无论是在 之前还是之后git checkout bar，您都会遇到更多麻烦。

因为你没有做那些事情，git reset --hard才是答案。

为什么会这样

git stash通常，什么是进行两次提交。一个保存当前索引，另一个保存当前工作树。¹ 这些提交在几个方面有点特殊；最重要的是，它们根本不在任何分支上。² 提交后，git stash然后正常运行git reset --hard. ³

该git reset --hard步骤的作用是使索引和工作树与当前提交匹配。也就是说，我们已经在存储中保存了（整个）索引和（整个跟踪部分）工作树；所以无论当前提交和索引之间有什么不同HEAD，都可以重新设置为相同；提交和工作树之间的任何不同HEAD，都可以重新设置为相同。

在 之后git reset，索引和工作树都是“干净的”，正如人们git status所说：它们都与HEAD提交匹配。然后您可以使用git checkout其他分支，因为您没有未保存的工作。然后git stash apply，您可以尝试，甚至git stash pop将您的更改“移动”到另一个分支。

当失败时——如在这种情况下——藏匿处保留在保存的藏匿处。当前索引和工作树现在充满了合并冲突。如果您运行git reset --hard，Git 将HEAD像往常一样重新设置索引和工作树以匹配提交，这样您将回到执行该git checkout步骤后的相同情况。由于您没有未保存的工作（您保存的工作仍在存储提交中），因此您在这里没问题。

（如果您确实有未保存的工作，则该git stash apply步骤将通过尝试合并隐藏的工作树更改来破坏未保存的工作。通常，这很难撤消。）

¹虽然git stash通常进行两次提交，但如果您使用--all或运行它--include-untracked，它将进行三次提交。我喜欢将这些称为i(index)、w(work-tree) 和u(untracke files) 提交。

使用--allor 时--include-untracked，saveorpush步骤不仅会做更多的事情git reset --hard：它还将运行git clean以删除进入第三次提交的任何内容（仅未跟踪的文件或未跟踪的包括忽略的文件）。git clean在应用这样的存储之前，您可能必须重复这项工作，这既棘手又烦人。

稍后，当您运行 时git stash apply，Git 将（尝试）应用该u提交（如果存在）。它将始终（尝试）应用w提交。只有在您给它标志时，它才会（尝试）应用i提交。在围绕整个“单独索引恢复”内容的许多版本中都有一些小错误。它们往往会影响想要在例如预提交钩子中使用和标志的人。--indexgit stash--keep-index--index

请注意，这git stash pop只是git stash apply && git stash drop: 也就是说，尝试应用 stash，然后，如果 Git 认为apply进展顺利，drop那么 stash也是如此。我发现最好先使用git stash apply，即使Git 认为它运行良好，也可以避免丢弃存储，因为 Git 和我有时不同意“运行良好”的含义。:-)

² Git 使用名称refs/stash来记住当前的 stash，并且 (ab) 使用 reflog forrefs/stash来维护“stash stack”的其余部分。分支名称内部都有形式，所以不是分支名称。refs/heads/namerefs/stash

³如果您使用git stash --keep-index，它运行的不仅仅是git reset --hard：它将保存的索引状态提取到工作树。这里的目标是让工作树按照设置索引的方式设置，以便您可以测试将要提交的内容。正如脚注 1 中所指出的，这里有一个小但相当讨厌的错误git stash，其中包含许多版本的，如果正确的工作树版本与版本匹配，则隐藏的工作树状态会意外地采用索引版本而不是工作树HEAD版本。