请注意，未来的Git 2.5(2015年第二季度)可能会试图让这种情况不可能发生。

参见Jeff King (peff)， 2015年4月22日的commit ed178ef。 (由Junio C Hamano合并- gitster -在commit 05c3967, 2015年5月19日)

注:这已被恢复。见下文。

Stash:需要一个干净的索引来应用/pop

问题

如果你在你的索引中有阶段性的内容并运行"stash apply/pop"，我们可能会遇到冲突并将新的条目放入索引中。 在这一点上，恢复到原始状态是很困难的，因为像“git reset—keep”这样的工具会破坏任何已准备好的东西。

换句话说:

“git stash pop/apply”忘记确保不仅工作树是干净的，而且索引是干净的。 后者很重要，因为存储应用程序可能会发生冲突，而索引将用于解决冲突。

解决方案

我们可以通过在有阶段性变化时拒绝应用来使其更安全。 这意味着如果之前有合并，因为在修改文件上应用了一个stash(添加但未提交)，现在它们将不再是任何合并，因为stash apply/pop将立即停止:

Cannot apply stash: Your index contains uncommitted changes.

强制你提交更改意味着，在合并的情况下，你可以通过git重置轻松地恢复初始状态(在git stash apply/pop之前)——这很难。

参见Jeff King (peff)的commit 1937610(2015年6月15日)和commit ed178ef(2015年4月22日)。 (由Junio C Hamano—gitster—在commit bfb539b中合并，2015年6月24日)

那次提交是为了提高申请的安全性 一个隐藏，因为应用程序进程可能创建 索引项冲突，之后很难恢复 原始索引状态。 不幸的是，这损害了一些围绕“git stash -k”的常见工作流，比如:

git add -p       ;# (1) stage set of proposed changes
git stash -k     ;# (2) get rid of everything else
make test        ;# (3) make sure proposal is reasonable
git stash apply  ;# (4) restore original working tree

如果你在步骤(3)和(4)之间“git提交”，那么这个 只是工作。但是，如果这些步骤是预提交的一部分 钩子，你没有那个机会(你必须恢复。 原始状态，无论测试是否通过或 失败)。

我也有过类似的经历。我还不想把文件放在舞台上，所以我用git add添加了它们，然后做了git reset。这基本上只是添加，然后取消我的更改，但清除未合并的路径。

git restore --staged  name-of-file-that-has--merge-conflict

请注意，未来的Git 2.5(2015年第二季度)可能会试图让这种情况不可能发生。

参见Jeff King (peff)， 2015年4月22日的commit ed178ef。 (由Junio C Hamano合并- gitster -在commit 05c3967, 2015年5月19日)

注:这已被恢复。见下文。

Stash:需要一个干净的索引来应用/pop

问题

如果你在你的索引中有阶段性的内容并运行"stash apply/pop"，我们可能会遇到冲突并将新的条目放入索引中。 在这一点上，恢复到原始状态是很困难的，因为像“git reset—keep”这样的工具会破坏任何已准备好的东西。

换句话说:

“git stash pop/apply”忘记确保不仅工作树是干净的，而且索引是干净的。 后者很重要，因为存储应用程序可能会发生冲突，而索引将用于解决冲突。

解决方案

我们可以通过在有阶段性变化时拒绝应用来使其更安全。 这意味着如果之前有合并，因为在修改文件上应用了一个stash(添加但未提交)，现在它们将不再是任何合并，因为stash apply/pop将立即停止:

Cannot apply stash: Your index contains uncommitted changes.

强制你提交更改意味着，在合并的情况下，你可以通过git重置轻松地恢复初始状态(在git stash apply/pop之前)——这很难。

参见Jeff King (peff)的commit 1937610(2015年6月15日)和commit ed178ef(2015年4月22日)。 (由Junio C Hamano—gitster—在commit bfb539b中合并，2015年6月24日)

那次提交是为了提高申请的安全性 一个隐藏，因为应用程序进程可能创建 索引项冲突，之后很难恢复 原始索引状态。 不幸的是，这损害了一些围绕“git stash -k”的常见工作流，比如:

git add -p       ;# (1) stage set of proposed changes
git stash -k     ;# (2) get rid of everything else
make test        ;# (3) make sure proposal is reasonable
git stash apply  ;# (4) restore original working tree

如果你在步骤(3)和(4)之间“git提交”，那么这个 只是工作。但是，如果这些步骤是预提交的一部分 钩子，你没有那个机会(你必须恢复。 原始状态，无论测试是否通过或 失败)。

参见man git merge(如何解决冲突):

在看到冲突后，你可以做两件事: 决定不合并。唯一需要清理的是将索引文件重置为HEAD提交到反向2。并清理2所做的工作树更改。和3。Git-reset -hard可以用于此。 解决冲突。Git会在工作树中标记冲突。编辑文件并将其添加到索引中。使用git commit来完成交易。

在TRUE MERGE下(看看2。和3。指):

当不清楚如何调和这些变化时，会发生以下情况: HEAD指针保持不变。 MERGE_HEAD ref被设置为指向另一个分支头。 干净合并的路径在索引文件和工作树中都被更新。 .．.

所以:使用git reset——如果你想从你的工作树中删除隐藏的变化，或者如果你只想清理索引并将冲突留在你的工作树中手工合并，git reset很难。

在man git stash (OPTIONS, pop)下，您还可以阅读:

应用状态可能会因冲突而失败;在这种情况下，它不会从收藏列表中删除。你需要手动解决冲突，然后手动调用git stash drop。

如果像我一样，您通常想要的是用存储文件的内容覆盖工作目录的内容，并且仍然会产生冲突，那么您想要的是使用git签出(their)来解决冲突。从根开始。

在此之后，您可以将git重置以将所有更改从索引转移到工作目录，因为很明显，在发生冲突的情况下，对非冲突文件的更改将保留在索引中。

你可能还想在之后运行git stash drop [<stash名称>]来摆脱这个stash，因为git stash pop不会在冲突的情况下删除它。