在git重置后——很难，git状态给了我在Changes not staging for commit:部分中的文件。
我也试过git reset .， git checkout。而git check - out-index -f -a，毫无用处。
那么，我怎样才能摆脱这些未分阶段的变化呢?
这似乎只影响Visual Studio项目文件。奇怪。请看这个粘贴:http://pastebin.com/eFZwPn9Z。这些文件的特殊之处在于，在.gitattributes中我有:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
另外，在我的全局.gitconfig中，selflf被设置为false。这有什么关系吗?
当前回答
我已经通过以下步骤解决了这个问题
从Git的索引中删除每个文件。 Git rm——cached -r。 重写Git索引以获取所有新的行结束符。 Git重置——很难
解决方案是配置Git处理行结束部分描述的步骤的一部分
其他回答
好吧，我差不多把问题解决了。
看起来。gitattributes文件包含:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
使项目文件出现非阶段性。我不知道为什么会这样，我真的希望了解git的人会给我们一个很好的解释。
我的修复是删除这些文件，并在.git/config的[core]下添加自专制= false。
这与前面的配置并不完全相同，因为它要求每个开发人员都具有selflf = false。我想找个更好的办法。
编辑:
我注释了那些有罪的句子，然后取消注释，它起作用了。搞什么…我甚至不……！
可能原因1 -行结束归一化
可能发生这种情况的一种情况是，在没有正确配置行结束符(1)的情况下，将有问题的文件签入存储库，导致存储库中的文件行结束符不正确，或者行结束符混合。要确认，验证git diff只显示行结束符的变化(默认情况下这些可能不可见，尝试git diff | cat -v查看回车为字面^M字符)。
随后，可能有人添加了.gitattributes或修改了内核。(2).基于.gitattributes或全局配置，Git已经对你的工作副本应用了本地更改，应用了所请求的行结束规范化。不幸的是，由于某些原因，git reset—hard并没有撤消这些行规范化的更改。
解决方案
重置本地行结束符的变通方法不能解决问题。每次文件被git“看到”时，它都会尝试重新应用规范化，从而导致相同的问题。
最好的选择是让git应用它想要的规范化，通过规范化repo中的所有行结束符来匹配.gitattributes，并提交这些更改——参见尝试用git filter-branch修复行结束符，但运气不好。
如果你真的想尝试手动恢复对文件的更改，那么最简单的解决方案似乎是删除修改过的文件，然后告诉git恢复它们，尽管我注意到这个解决方案似乎不能100%一致地工作(警告:如果你修改的文件除了行尾之外有更改，请不要运行这个!!):
git status --porcelain | grep "^ M" | cut -c4- | xargs rm
git checkout -- .
注意，除非您在某个时候对存储库中的行结束符进行了规范化，否则您将继续遇到这个问题。
可能原因2 -不区分大小写
第二个可能的原因是Windows或Mac OS/X不区分大小写。例如，存储库中存在如下路径:
/foo/bar
现在Linux上有人将文件提交到/foo/Bar(可能是由于构建工具或其他创建该目录的工具)并推送。在Linux上，这实际上是两个独立的目录:
/foo/bar/fileA
/foo/Bar/fileA
在Windows或Mac上签出这个repo可能会导致修改后的fileA不能被重置，因为在每次重置时，Windows上的git都会签出/foo/bar/fileA，然后因为Windows不区分大小写，会用/foo/bar/fileA覆盖fileA的内容，导致它们被“修改”。
另一种情况可能是repo中存在的单个文件，当在不区分大小写的文件系统上签出时，它们将重叠。例如:
/foo/bar/fileA
/foo/bar/filea
可能还有其他类似的情况会导致这样的问题。
不区分大小写的文件系统上的Git应该真正检测到这种情况并显示有用的警告消息，但目前没有(这在未来可能会改变——请参阅本讨论和Git的相关补丁。Git邮件列表)。
解决方案
解决方案是使git索引中的文件大小写与Windows文件系统中的大小写保持一致。这既可以在Linux上完成，它将显示事物的真实状态，也可以在Windows上使用非常有用的开源实用程序Git-Unite。git - unite将对git索引应用必要的case更改，然后将其提交给repo。
(1)这很可能是有人使用Windows，没有任何。gitattributes定义的文件，并使用默认的全局核心设置。这是错误的(见(2))。
(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
这些方法都不适合我，唯一的解决方案是核整个回购和重新克隆它。这包括存储，重置，添加然后重置，clrf设置，大小写敏感性等。叹息……
我遇到的另一种可能性是，存储库中的一个包最终具有分离的HEAD。如果这里的答案都没有帮助，你遇到了这样的git状态消息，你可能有同样的问题:
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: path/to/package (new commits)
进入路径/to/package文件夹，git状态应该产生以下结果:
HEAD detached at 7515f05
下面的命令应该修复这个问题，master应该被你的本地分支替换:
git checkout master
您将得到一条消息，您的本地分支将在远程分支后面提交一些数量的文件。快点拉，你应该脱离险境了!
我已经通过以下步骤解决了这个问题
从Git的索引中删除每个文件。 Git rm——cached -r。 重写Git索引以获取所有新的行结束符。 Git重置——很难
解决方案是配置Git处理行结束部分描述的步骤的一部分
