git重置后留下未更新的变化–hard
标题说明了一切。
在git reset --hard ， git status给了我的文件在Changes not staged for commit:部分。
我也试过git reset . ， git checkout -- . 和git checkout-index -f -a ，无济于事。
那么，我怎样才能摆脱那些未分离的变化呢？
这似乎只命中Visual Studio项目文件。 奇怪的。 看到这个贴： http : //pastebin.com/eFZwPn9Z 。 这些文件有什么特别的，是在.gitattributes我有：
*.sln eol=crlf *.vcproj eol=crlf *.vcxproj* eol=crlf
此外， autocrlf在我的全局.gitconfig设置为false。 这可能有点相关吗？
我有同样的问题，它与.gitattributes文件有关。 但是导致问题的文件types没有在.gitattributes指定。
我能够通过简单的运行来解决这个问题
git rm .gitattributes git add -A git reset --hard
Git将不会重置不在存储库中的文件。 所以你可以：
$ git add . $ git reset --hard
这将进行所有更改，这将导致Git知道这些文件，然后重置它们。
如果这不起作用，您可以尝试存储并放弃您的更改：
$ git stash $ git stash drop
解决！！！
我已经解决了这个问题，使用下面的stpes
1）从Git的索引中删除每个文件。
git rm --cached -r .
2）重写Git索引来获取所有新的结尾。
git reset --hard
解决scheme是在git站点上描述的步骤的一部分https://help.github.com/articles/dealing-with-line-endings/
好的，我解决了这个问题。
这似乎是.gitattributes文件，其中包含：
*.sln eol=crlf *.vcproj eol=crlf *.vcxproj* eol=crlf
使项目文件显示不分配。 我无能为力，我真的希望有人知道git的方式会给我们一个很好的解释。
我的修复是删除这些文件，并添加autocrlf = false在[core] .git/config 。
这不会和以前的configuration完全一样，因为它要求每个开发者都有autocrlf = false 。 我想找一个更好的解决办法。
编辑：
我评论了罪名，没有评论他们，它的工作。 什么…我甚至不… …！
我有同样的问题和隐藏，硬重置，干净，甚至所有的人仍然留下的变化。 原来问题是没有被git正确设置的x文件模式。 这是一个“已知问题”，用于Windows的git。 本地更改显示为gitk和git status作为旧模式100755新模式100644，没有任何实际的文件差异。
解决方法是忽略文件模式：
git config core.filemode false
更多信息在这里
可能的原因 – 线结束标准化
发生这种情况的一种情况是：当文件被检查到存储库中时，如果没有正确的行结束configuration[1]，导致存储库中的文件存在不正确的行结尾或混合行结束符。 要确认，确认git diff只显示行尾的变化（默认情况下这些变化可能不可见，请尝试使用git diff | cat -v将回车看作文字^M字符）。
随后，某人可能会添加一个.gitattributes或者修改core.autocrlf设置来规范行尾[2]。 基于.gitattributes或全局configuration，Git已经将本地更改应用到您的工作副本，并将所需的行结束标准化。 不幸的是，出于某种原因， git reset --hard并没有取消这些行标准化的改变。
解
本地行结束重置的解决方法不能解决问题。 每次文件被git“看到”，它都会尝试重新应用规范化，导致同样的问题。
最好的select是让git应用规范化，通过标准化回购库中的所有行结尾来匹配.gitattributes ，并提交这些更改 – 请参阅尝试使用git filter-branch修复行结尾，但没有运气 。
如果你真的想尝试恢复文件的变化手动然后最简单的解决scheme似乎是擦除修改后的文件，然后告诉GIT恢复他们，虽然我注意到这个解决scheme似乎并不一致100％的工作时间（ 警告：不要运行这个，如果你的修改文件有改变以外的结局!!）：
git status --porcelain | grep "^ M" | cut -c4- | xargs rm git checkout -- .
请注意，除非您在某些时候对存储库中的行结束进行规范化处理，否则您将继续遇到此问题。
[1]这很可能是由某人使用Windows，没有任何.gitattributes定义的文件，并使用默认的全局设置为core.autocrlf是false （见[2]）。
[2] http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
另一个原因可能是不区分大小写的文件系统 。 如果在同一级别的回购库中有多个文件夹，其名称只是大小写不同，则会受到这个影响。 使用其Web界面（例如GitHub或VSTS）浏览源代码库以确保。
有关更多信息： https : //stackoverflow.com/a/2016426/67824
您可以stash您的更改，然后放下存储：
git stash git stash drop
运行干净的命令：
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`) git clean -fd
检查你的.gitattributes 。
在我的情况下，我有*.js text eol=lf在它和git选项core.autocrlf是true 。
这让我想到当git自动转换文件行结束并阻止我修复它甚至是git reset --hard HEAD没有做任何事情。
我解决它与评论*.js text eol=lf在我的.gitattributes和取消注释它之后。
看起来像只是魔法。
我有同样的问题。 我做了git reset --hard HEAD但仍然每次我做git status我看到一些文件被修改。
我的解决scheme相对简单。 我刚刚closures了我的IDE（这里是Xcode），并closures了我的命令行（这里是我的Mac OS上的terminal），并再次尝试它，它的工作。
然而，我始终无法find问题的起因。
这些方法都不适合我，唯一的解决办法是把整个回购重新复制并重新克隆。 这包括存储，重置，添加然后重置，clrf设置，区分大小写等。
我遇到了一个类似的问题，涉及.gitattributes ，但我的情况涉及到GitHub的LFS。 虽然这不完全是OP的情况，但我认为它提供了一个机会来说明.gitattributes文件的function，以及为什么会导致以“幻影”差异forms进行非暂时性更改。
就我而言，一个文件已经在我的仓库中，就像从一开始就一样。 在最近的一个提交中，我添加了一个新的git-lfs track规则，它使用了一个事后看起来有点太宽泛的模式，最终匹配这个古老的文件。 我知道我不想改变这个文件; 我知道我没有改变这个文件，但是现在它已经进入了我的未分阶段的修改，那个文件上没有任何结账或硬重置的东西可以修复它。 为什么？
GitHub LFS扩展主要通过利用git通过.gitattributes文件提供访问的钩子来工作。 通常， .gitattributes条目指定如何处理匹配文件。 在OP的情况下，它是关于正常化的行结束; 在我的，是让LFS处理文件存储。 在任何一种情况下， git在计算git diff时看到的实际文件都与您在检查文件时看到的文件不匹配。 因此，如果通过匹配它的.gitattributes模式更改文件的处理方式，即使文件中没有任何更改，它也会在状态报告中显示为未分离的更改。
所有这一切，我对问题的“回答”是，如果.gitattributes文件中的变化是你想要做的事情，你应该真的应该添加变化，继续前进。 如果不是，那么修改.gitattributes以更好地表示你想要做什么。
参考
-
GitHub的LFS规范 – 他们如何挂钩到
clean和smudge函数的伟大的描述调用git对象replace您的文件与一个简单的文本文件与散列。 -
gitattributes文档 – 所有可用的定制
git如何处理文档的细节。
我相信git有一个问题，那就是git会在结帐时随机写入错误的行结尾，唯一的解决方法是签出其他分支并强制git忽略更改。 然后检查你实际上想要处理的分支。
git checkout master -f git checkout <your branch>
请注意，这将丢弃您可能有意做出的任何更改，因此只有在结账后立即出现此问题才能执行此操作。
编辑：我可能第一次真的很幸运。 事实certificate，我切换后的分支再次得到了一点。 事实certificate，文件git报告修改分支后更改修改。 （显然是因为git没有一贯地将CRLF行结尾应用于文件。）
我更新到Windows的最新git，希望问题没有了。
类似的问题，虽然我只能确定表面。 无论如何，它可能会帮助某人：我所做的（FWIW，在SourceTree中）：隐藏未提交的文件，然后进行硬复位。
正如其他答案所指出的，问题是由于线端自动校正。 我遇到了* .svg文件的这个问题。 我在我的项目中使用svg文件的图标。
为了解决这个问题，我让git知道svg文件应该被视为二进制而不是文本，通过将下面的行添加到.gitattributes
* .svg二进制
