我做了git stash save然后git pullgit stash pop现在我有冲突，我想重置一个文件，使其与从存储中删除更改相同（我在其他文件中进行了其他更改我想保持）。从存储冲突后强制检出文件
我已经试过：
git checkout -f inst/app/server.R
，但得到警告：
warning: path 'inst/app/server.R' is unmerged
和文件是不变的，我还是有内部冲突标记。我如何从上次提交结算该文件？
TL; DR：听起来像是你想要的git checkout --ours inst/app/server.R。
您处于冲突合并中，所以有两个“上次提交”。一个是你的HEAD（当前）提交。请注意，您当前的提交是您在运行命令时所在的那个提交，除非您的命令是git rebase，在这种情况下，事情会被交换：请参见What is the precise meaning of "ours" and "theirs" in git?由于您说最后一条命令是因合并冲突而失败的命令git stash apply，当前的提交是后您的git pull跑一次成功git merge您所做的一个，和其他承诺是多次提交的一个在当前的git stashstash-bag名下[email protected]{0}（又名只是stash） 。
（还有第三个承诺卷入任何冲突的合并，这是合并基础。这可能是储物箱，这是一个有点怪异不太相关，但值得一提的。请注意，如果您设置merge.conflictStyle到diff3在你的Git配置中，你会得到合并版本，其中有一组额外的冲突标记|||||||，在<<<<<<<和>>>>>>>之间显示你的“我们的”和“他们的”版本，我想保留diff3设置为它告诉我之前我有什么 - 他们都以相互冲突的方式更改文件。）
当您运行git checkout没有命名特定的提交，或者使用--ours或--theirs选项，Git会尝试从索引获取版本。 （请记住，指数也被称为临时区域有时缓存 -is你在哪里建设下一个承诺，你会做）。但是一个矛盾合并叶子在版本所有冲突的文件指数。 Git不知道要得到哪一个，所以它会因为这个错误而失败。使用--ours告诉git checkout将文件的“我们的”（即，HEAD）版本从索引复制到工作树;使用--theirs告诉git checkout复制文件的“其他”（即，MERGE_HEAD）版本。
当您从索引中提取其中一个版本时，会在索引中留下其他两个版本，即使文件处于未解决合并状态。 仔细检查内容以确保你有正确的版本，然后git add该文件来解决冲突。这将清除三个单独的索引版本，将工作树版本放入“已解决”索引插槽（插槽零）。
如果您需要重新创建合并冲突，你可以使用git checkout -m -- path（如果path类似于一个选项--时，才需要的，但它是一个很好的习惯进入）。直到您运行git commit才能完成失败的合并。
一旦一切按照你想要的方式解决，使用git commit完成合并。
你说git stash pop，但git stash pop只是一个快捷方式，意思是“运行git stash apply然后，当且仅如果成功，运行git stash drop。”由于应用程序步骤失败，一旦您确信存储已经干净地应用并被提交，您将不得不手动运行git stash drop。
我建议避免使用git pull。它所做的就是为你运行另外两个Git命令：git fetch，然后是git merge或git rebase，具体取决于你提前告诉Git。最好单独运行这两个命令，以便：
git fetch提取。没有什么根本性的错误使用git pull，只记得它是真正git fetch && git something，你必须提前决定“东西”的一部分。如果你不选择一个，Git会选择git merge，这可能是错误的默认设置，但Git在2005年首先做了什么，因此无法更改。 :-)
没有--base选项，但您可以使用gitrevisions syntax从索引访问：git checkout -- :1:path。您可以使用相同的语法获得--ours版本（索引条目＃2）和--theirs版本（它是＃3），但无论如何，它更容易记住--ours和--theirs。
的“我们的”版本有时也被称为当地版本，而“他们”的版本有时也被称为远程版本，但我讨厌这些名字。特别是“遥控”太容易与遥控器origin和遥控分机名称origin/master混淆。