我还没有在我的分支中提交更改。我决定应用我的一些藏匿处。Stash 应用了自动合并和冲突。我意识到，隐藏的更改不适合我，并且想要取消隐藏更改，但不要在存储之前松开我的更改。试图做
git stash show -p | git apply -R
但这对我不起作用。我有错误消息：错误：补丁失败，...错误：补丁不适用
如何撤消存储应用而不丢失我未提交的更改？
反向应用存储的问题是由于合并冲突造成的。如果您想深入了解这一点，我将在最后详细介绍这一点，但更重要的是：该怎么办？
通常git stash apply是一个相当安全的命令。它要求工作树与索引匹配，并且只期望写入工作树，因此看起来很容易撤消。
不过，当存在冲突时，这可能会有点痛苦，因为现在它会更新冲突解决的索引。所以现在每个文件有（至少）五种可能的状态：
1) 您的本地更改和存储应用的更改都没有对文件进行更改。这没东西看。
2) 您对文件应用了本地更改，但存储并未对文件应用更改。您本地更改的版本位于索引中，您可以保留此文件。
3) 您尚未对文件应用本地更改，但存储确实对其应用了更改。该索引包含由存储修改的文件。这看起来非常类似于情况 2，因此了解差异是第一个挑战（见下文）；一旦您识别出处于这种状态的文件，您可以将该文件恢复到之前提交的版本（但可能还不想这样做；再次参见下文）
git checkout HEAD -- file/with/only/stashed/changes
4) 您已对文件应用了本地更改，而存储对同一文件应用了冲突的更改。在这种情况下，文件的冲突标记版本位于工作树中。你可以通过说恢复你的版本
git checkout --ours -- file/with/conflicting/changes
5) 您已将本地更改应用到文件，并且存储应用了对同一文件的更改，但更改不冲突（即自动合并解析成功组合了更改）。这是最大的问题案例。它再次看起来非常类似于情况 2 和 3，要修复它，您需要将您的更改与存储添加的更改分开。
好的，所以情况 1 和 2 不采取任何操作，而情况 4 很容易找到并解决。问题是 3 和 5。有两种方法可以解决这个问题：
基于您之前尝试执行的操作，您可以从存储中存储补丁并删除冲突文件的条目。然后您可以使用 解决冲突checkout --ours，并反向应用补丁的其余部分。
您可以使用逐个文件来处理它
git stash show --name-only
查看存储是否修改了文件，以及类似的内容
git diff stash -- path/to/file
查看文件是否包含本地修改。您仍然需要对在两个地方都修改过的文件执行反向修补之类的操作，而不会发生冲突。
为什么补丁不起作用
由于存在冲突标记，无法将存储库作为补丁反向应用。例如，也许您从一个文件开始
this
is
content
并且藏匿者想将其更改为
here
is
content
但你已经在本地将其更改为
this
file contains
content
所以他们stash apply发生了冲突。好吧，现在工作副本说
<<<<<<< Updated upstream
this
file contains
=======
here
is
>>>>>>> stashed changes
content
存储中的反向补丁会将第 1 行从 更改为here，但在第 1 行this找不到here
| 归档时间： |
|
| 查看次数： |
5740 次 |
| 最近记录： |