我们做了一些不好的事情。合并冲突期间`git stash`
我们在合并冲突期间运行git stash save，现在我们无法恢复我们的工作。
的事情，我们已经试过：
git pull -Xours origin master
git stash apply --index
和：
git pull origin master
git stash save --keep-index "merge conflicts"
git stash apply [email protected]{1}
请帮帮忙！
当您处于冲突状态（索引和工作目录）时，您将无法执行git stash - 它会在发生未合并条目时发生错误。
确保您确实已经完成了存储。见git stauts和git stash show
在'git stash'之前，我解决了冲突并继续使用'git add'。这是我有'git add'我的决议后，我做了进一步的编辑，然后做了'git stash save msg'。所以这确实成功了。 –
@bukzor实际上，我只是在Windows 7上用msysgit 1.8.3进行了测试。如果文件存在冲突（即没有尝试解决合并冲突），那么'git stash save'确实会中止，而没有存储冲突的文件。所以***这其实是正确的，这不是假的***。 – 2013-08-10 00:27:39
这个问题似乎是git stash不保存到你试图在合并分支中的基准输出。在合并，这是存储在一个名为MERGE_HEAD参考。
要修复它，并重新回到以前的状态，你需要找到的版本（让我们假装这是d7a9884a380f81b2fbf002442ee9c9eaf34ff68d）你试图合并中，并设置MERGE_HEAD它应用藏匿后。
那么你可以申请藏匿（与--index重新阶段这是之前上演的一切），并设置您的MERGE_HEAD：
git stash apply --index
git update-ref MERGE_HEAD d7a9884a380f81b2fbf002442ee9c9eaf34ff68d
尽管上面看起来对我来说是真实的，但我并不完全相信只要设置MERGE_HEAD和去除干净就足以恢复合并状态。如果可能的话，我会避免在冲突期间使用git存储。 – user1338062
我也会，但在这一点上是后见之明。 – bukzor
鉴于你最后的评论：您可以使用
git stash megre --no-commit <branch>
把指数在“合并”状态，而不会提交修改
然后用你想要的修改：
，如果你已经工作了您的合并中藏匿：
git reset #to remove the "conflicts" flags
git checkout <initial commit> -- ./ #to revert everything to the previous working state,
git stash apply #apply your changes
，一旦一切都在期望的状态，git commit
关于bukzor的评论是：居然有一个大git checkout <tree-ish>与git checkout <tree-ish> -- <files>之间的差异。
git checkout <branch>：本表由更新索引，工作树切换分支，和HEAD以反映指定的分支或提交。
git checkout [-p|--patch] <tree-ish> -- <pathspec>：当<路径>或--patch给出时，git checkout不会切换分支。它从索引文件或命名为<的树形文件>（通常是提交）更新工作树中的命名路径。
git checkout <initial commit>确实会丢弃合并信息。
git checkout <initial commit> -- ./（注意额外的-- ./）则保留合并信息，并将每个被跟踪文件恢复到其状态<initial commit>。
我今天做了同样的事情，并采取了一种不同的方法（在试错之后）返回隐藏之前的状态，以便继续解决冲突并完成合并。
首先，在清除目标分支中的部分合并之后，我捕获了剩余冲突的文件列表（文本文件或编辑器选项卡）。这只是清空之后非挂起文件的列表，因为已经解决冲突的文件在存储之前会被暂存。
$ git status
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: myproject/src/main/java/com/acme/package3/Class3.java
# modified: myproject/src/main/java/com/acme/package3/Class4.java
#
接着，我创建一个补丁，并重置分支返回到预合并状态：
$ git diff HEAD > ~/merge-with-resolved-conflicts.patch
$ git reset --hard HEAD
然后创建了一个临时分支（从合并目的地分支来源的），和施加补丁：
$ git checkout -b my-temp-branch
$ git apply ~/merge-with-resolved-conflicts.patch
$ git commit -a -m "Merge with resolved conflicts"
所以我-TEMP分支的HEAD现在包含被合并，包括与冲突的文件解决，剩余冲突的文件的一切。
然后我切换回原来的分支，再合并，看了看git的状态
$ git checkout my-branch
$ git merge other-branch
$ git status
的状态显示的文件有冲突的完整列表：
# Unmerged paths:
# (use "git add <file>..." to mark resolution)
#
# both modified: myproject/src/main/java/com/acme/package1/Class1.java
# both modified: myproject/src/main/java/com/acme/package2/Class2.java
# both modified: myproject/src/main/java/com/acme/package3/Class3.java
# both modified: myproject/src/main/java/com/acme/package3/Class4.java
#
现在我需要比较这两个文件列表。第二个列表中的所有文件都已经解析（在本例中为Class1.java和Class2.java）。因此，对于每个这些文件，我在版本拉从临时党支部解决的冲突（如摘樱桃，但对于单个文件，而不是一个完整的提交）：
$ git checkout my-temp-branch myproject/src/main/java/com/acme/package1/Class1.java
$ git checkout my-temp-branch myproject/src/main/java/com/acme/package2/Class2.java
这样做之后，我回来了到存储之前的状态，所以我可以恢复解决剩余的冲突并提交合并。（合并冲突期间git的藏匿处弹出）
我的解决办法摆脱这种的是：
创建并检出一个新的（本地）分支mytemporarybranch
的Git分支mytemporarybranch & & git结帐mytemporarybranch
提交到这个mytemporarybranch
git的承诺-m “我凌乱的合并和壁球”
结账myoriginalbranch
git的结帐myoriginalbranch
合并正确（无剥落流行/应用此一次！）
壁球合并mytemporarybranch到myoriginal分支
混帐合并--squash mytemporarybranch
你真的做了什么重要的事吗？ （你是否真的需要恢复隐藏的更改？）你能重置掉尝试的合并，然后重新执行吗？ – Cascabel
分别是和否。这些更改由多个合并冲突解决方案组成。 – bukzor
@bukzor：如果您需要更多的一天来解决合并冲突问题，那么可能需要重新考虑有关分支处理和工作分配（或合并频率）的策略。如此冗长的合并解决方案毕竟是一个很好的来源，因为在一次提交中所做的更改量很难找到错误 – Grizzly