我经常尝试检查一个新的远程分支（从中创建一个本地分支，但这可能与我的问题无关）并且git因以下错误而失败
错误：结帐后，您对以下文件的本地更改将被覆盖：
请提交您的更改或存储它们，然后才能切换分支。
现在，当我看到这一点时，人们可以天真地期望如果一个人藏匿更改，检查新分支然后应用隐藏的更改然后会发生冲突，但几乎不会发生这种情况。会发生什么事情是隐藏的变化适用于干净，并且我在检查新分支之前不会丢失任何东西。为什么git会给出这个看似误导性的错误？ 如果我可以在结账之前藏匿并在最后清理地应用藏匿处，为什么不能git checkout在引擎盖下做什么？
编辑：
为了更清楚，我不是在问为什么结账失败，或者为什么有时候一个脏工作区的结账成功，我明白这一切。我的问题是，在这种情况下，有一个100％无数据丢失的行动方案（或者是否存在一些我无法看到数据丢失的极端情况）所以为什么没有git只是做到了吗？
如果我对git的新用户说文件foo第100行上的modif会与文件foo第2行上的另一个modif冲突，那么他们接受它就是真理，不要抱怨，很容易解决冲突。但是因为git是一个很好的工具，它可以做到聪明的事情，甚至不会打扰你，它可以修复它没有任何腐败风险的问题。为什么在这种情况下git checkout不是同一个哲学？
答案 0 :(得分：3)
如果必须删除某些已修改的文件并替换为结帐操作，git checkout命令会抱怨（并且不会切换分支）。
这意味着工作树版本和HEAD版本之间存在差异（以便修改文件）和 HEAD版本之间的差异和目标提交（以便必须替换文件）。
它不意味着工作树版本和HEAD版本之间的差异以任何方式与目标提交冲突，只是目标提交与{{1}不同提交和HEAD提交与工作树版本不同。例如，假设HEAD的工作树版本在35行中的第17行中将“color”的拼写更改为“color”，并且从README版本到目标版本的差异添加了请注意文件的末尾（添加第36行）。在这种情况下，应用拼写更改也很简单，但HEAD不会这样做，它只会拒绝检查目标提交。
[编辑添加，来自评论]并不是git checkout无法进行合并，只是默认情况下不会。使用git checkout告诉git checkout -m使用合并代码。