我在Windows上使用git（1.8.3）。 如果我从github克隆一个repo，然后立即检出该repo上的一个不同的分支，git检测修改后的文件。 通常 。 有时候不会。 所有修改后的文件的差异都是相同的（包括行结尾）。 在我的团队中至less有4台不同的个人电脑上有2个不同的回收站出现了这个问题。
它并不总是相同的文件，但它几乎总是rep中文件的几个子集之一。 例如，有时在回购的根目录中有5个相同的文件，有时在一个特定的文件夹中有93个文件，有时在同一个文件夹中有16个文件。
一旦git将文件标记为已修改，如果我还原或存储它们，它们会立即标记为已修改，这使得不可能在分支之间来回切换。
我感觉它与行结尾有关，但是我已经添加了推荐的.gitattributes文件并重新规范了每个分支，但是我仍然有这些零星的问题。 我想到的另一种可能性是在分支之间合并，但是我不知道如何testing这个理论。
我们都有core.autocrlf=true因为我们都在Windows上。 这是我们的.gitattributes
# Auto detect text files and perform LF normalization * text=auto # Custom for Visual Studio *.cs diff=csharp *.sln merge=union *.csproj merge=union *.sqlproj merge=union *.html text diff=html *.css text *.js text *.ejs text *.sql text # Standard to msysgit *.doc diff=astextplain *.DOC diff=astextplain *.docx diff=astextplain *.DOCX diff=astextplain *.pdf diff=astextplain *.PDF diff=astextplain
有两种情况我已经看到这种事情发生：
线路结局和Git试图处理跨平台的所有疯狂选项。 （我根本不使用这些功能，而且我更喜欢存储和处理所有包含一致的LF行结尾的文件，包括在Windows上）。
具有两个或更多文件的存储库名称仅在大小写不同的情况下存在。 例如， readme.txt和ReadMe.txt 。 Windows上的Git处理这些情况非常困难，因为只有一个底层文件可以通过两个不同的名字来访问。
永远不要将core.autocrlf设置为true ，始终为false 。
这很简单：这是一个全球性的背景，意想不到的后果。
如果你想用eol来管理某种类型的文档，只能通过.gitattributes文件和core.eol指令来完成 。
这意味着：首先摆脱所有目录自动更改（如你的* text=auto ），推动修改回上游回购，并看看问题是否依然存在。
然后，只有这样，重新引入这些指令，而不是为每个文件（而不是' * '），但只为你绝对想要正常化的文件。
并检查是否有效。