公元二〇一六年九月二十八日，新中国建国六十七年国庆前三天，有 重大发现！

基本可以确定问题所在：

原因就是 VS2015 创建项目时自动创建的 .gitattributes 文件，一直以来，我长期以来，都一直以为里面只有微软风格的“永远绝对正确”却“永远绝对没用”的注释，
但是，我错了，我今天偶然的发现，一个项目在 git 中的差异， 放这个文件 和 不放这个文件有差异！
——那就说明这个文件在起作用啊。里面有什么东西？
——是的有：
Line 4:* text=auto
——虽然全文只有这样有用，但是也因为全文3K的长度，只有这9个字符有用，所以忙碌的码农们自然没空细看，结果给微软坑死！

为什么发生问题的人很少？因为只有设置成“以原样签出，以原样签入”的时候，才会和这条配置发生奇妙的反应。。。。我真的也是醉了！

--- 重要的分割线 ----

2016.09.29 经过验证，我的推论完全正确，我已修复之前损坏的项目。
建议：大家对于 VS2015自动生成的 .gitattributes 文件直接删除掉。
提示：高科技是件危险的东西，在没搞懂之前，最好先估算下破坏程度再动手。

PS：热情的回答，长期的关注这个问题，居然 0 支持，0 感谢，知乎有句方言怎么说来着：

“贵乎药丸”。

----不再重要的分割线----

就是因为碰到这个问题，搜到这里来的，求大神！！！求深入了解Git原理的大神。

@轻扬 不是这个问题，如果是编码的问题，二进制比较的时候能比较出来。

@张宇航 问者，我们还是自己研究下吧，各位我们先列下自己的使用环境变量，看看有什么异同之处：

操作系统：Win10
开发工具：VS2015
版本工具：GitExtensions
出现位置：添加的子模块中。（刚刚试了把这个库单独拉出来，居然显示全部文件都不同。。。）
出现文件：目前有 *.cs *.sln 文件。
其它疑点：
这是一个很久的却在不断维护的库（从2013年开始建立，现在推送到的是OSC服务器上）
我有怀疑是 VS2015自带的 git版本（281）和 ge自带的版本（195）不匹配的问题，但是我用（195）的版本依然出现一样的结果。
2014.12日已经出现过一次情况，当时是全部作为更改提交。现在诡异的是，如果把项目切回这个更改以前，居然显示文件不用更改。——难道是以前某次 git 的bug导致文件散列码错误，现在修复了又改回去了？

PS：有E文好的往官方发 bug 报告了吗？
这个应该是因为 git 库中存入的散列值和实际计算值不同造成的？
可否通过清除 .git 目录里的缓存达到不再提示有的目的？
因为有些文件，原来是不显示为这种状态的，但是一旦打开修改，再修改还原回去，就造成了这样。

2016.09.10 新发现
在当前目录里面是二进制相同的，但是查看他们提交上去的文件，却会发现，日志中提交到服务器的文件的换行符是不同的。我这里因为在 Win 下使用，一般设置为“原样签出，原样签入”。不知道 @张宇航 的情况如何？问题应该还是出现在编码这里，似乎签出签入的换行符设置哪里有了故障。