如何解决git存储冲突没有提交？
正如在这个问题所问 ，我也想知道如何解决一个冲突的git stash pop而不添加所有修改提交（就像“git存储stream行”没有冲突呢）。
我目前的做法是非常冷酷，因为我这样做：
git stash pop -> CONFLICT git stash drop [resolve conflict] [add conflict files] git reset HEAD <all files that are in commit-mode>
[更新]一种重现它的方法：
mkdir foo; cd foo; git init echo "1" > one echo "2" > two git add -A; git commit -m "first" echo "1.1" > one echo "2.1" > two git stash echo "2.2" > two git commit -a -m "second" echo "Only this file would stay in HEAD without the conflict" > third git add third git stash pop git status
2016-06-27：在示例中添加了一个名为“third”的新文件，以显示像scy这样的解决scheme只能用于空HEAD，但是不能解决HEAD没有相同内容的初始问题为一个git stash pop没有冲突。
假设你有这种情况下，你藏起来的变化，以便从原点拉。 可能是因为您的本地更改只是debug: true在某些设置文件中为debug: true 。 现在你拉，有人在那里引入新的设置，造成冲突。
git status说：
# On branch master # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: src/js/globals.tpl.js no changes added to commit (use "git add" and/or "git commit -a")
好的。 我决定去Gitbuild议：我解决了冲突，并承诺：
vim src/js/globals.tpl.js # type type type … git commit -a -m WIP # (short for "work in progress")
现在我的工作副本处于我想要的状态，但是我创build了一个我不想拥有的提交。 如何在不修改工作副本的情况下摆脱该提交？ 等等，这是一个受欢迎的命令！
git reset HEAD^
我的工作副本没有更改，但WIP提交已经消失。 那正是我想要的！ （请注意，我在这里没有使用--soft ，因为如果在你的--soft有自动合并的文件，它们将自动进行，因此你最终会在reset后reset这些文件。）
但还有一件事情： git stash pop的man页面提醒我们： “应用状态可能会因为冲突而失败;在这种情况下，它不会从存储列表中移除，您需要手动解决冲突并调用git stash drop之后手动储存“。 所以这正是我们现在所做的：
git stash drop
并做了。
我不认为做一个提交，然后重置分支去除其他答案中提出的提交和类似的解决方法是解决这个问题的干净的方法。
下面的解决scheme似乎对我来说要干净得多，而且Git本身也提出了这个build议 – 在存储库中执行git status时会发生冲突：
Unmerged paths: (use "git reset HEAD <file>..." to unstage) (use "git add <file>..." to mark resolution)
让我们做Gitbuild议而不做任何提交：
- 手动（或使用一些GUI合并工具）解决冲突（S）。
- 使用
git reset将冲突标记为已解决并取消更改。 你可以在没有任何参数的情况下执行它，Git将从索引中删除所有内容。 你以前不必执行git add。 - 最后，使用
git stash drop删除存储，因为Git在冲突时不会这样做。
所以：
$ git stash pop # ...manually resolve conflict(s) $ git reset $ git stash drop
注意：冲突解决后向文件添加文件是有意的。 通过这种方式，您可以区分以前存储的更改和冲突解决后所做的更改。 如果你不喜欢它，你总是可以使用git reset从索引中删除所有的东西。
另一个说明：我强烈build议使用任何3路合并工具来解决冲突，例如KDiff3 。 它通常自动解决大部分冲突。
您可以使用git reset HEAD file来解决冲突，而无需暂存您的更改，而不是添加您为解决冲突所做的更改。
但是，您可能必须运行此命令两次。 一旦将冲突标记为已解决，一旦解除冲突解决程序所执行的变更即可。
有可能应该有一个复位模式，这两个同时做这些事情，虽然现在没有一个。
git checkout stash -- .
为我工作。
注意 ：这可能是危险的，因为它不会尝试将隐藏的更改合并到工作副本中，而是用隐藏的文件覆盖它。 所以你可以失去你未经承诺的改变。
看来这可能是你正在寻找的答案，我还没有尝试过这个，但它似乎可以做的伎俩。 使用这个命令，GIT将尝试应用以前的更改，而不尝试将它们全部添加到提交。
git stash apply --index
这里是完整的解释：
git stash branch将起作用，它会为你创build一个新的分支，当你隐藏你的工作时检查你所提交的内容，在那里重新应用你的工作，然后在成功应用的时候丢弃存储。 检查这个
我find的最快的方法是解决冲突，然后做git add -u ，然后做git reset HEAD ，甚至不涉及提交。
根据git存储的问题 ，在修复冲突之后， git add <file>是正确的行为。
在阅读了这个评论之后 ，我了解到这些更改会自动添加到索引（按devise）。 这就是为什么git add <file>完成冲突解决过程。
git add . git reset
git add . 将阶段所有的文件告诉混帐你已经解决了冲突
git reset将取消所有阶段文件，而不创build一个提交
