在git中更改分支会导致修改文件

Question

我在Windows上使用git（1.8.3）。如果我从github克隆一个repo然后立即检查该repo上的另一个现有分支，git会检测修改后的文件。 一般。有时却没有。并且所有修改过的文件上的差异都是相同的（包括行结尾）。在我的团队中至少4台不同的PC上的2个不同的回购中已经观察到这个问题。

它并不总是相同的文件，但它几乎总是代表中的几个文件子集之一。例如，有时它在repo的根目录中是相同的5个文件，有时它在一个特定文件夹中是相同的93个文件，有时它在不同文件夹中是相同的16个文件。

一旦git将文件标记为已修改，如果我还原或存储它们，它们会立即再次标记为已修改，这使得无法在分支之间来回切换。

我觉得它与行结尾有关，但我已经添加了推荐的.gitattributes文件和renormalized每个分支，但我仍然有这些零星的问题。我想到的另一种可能性是在分支之间合并，某种方式搞砸了我所做的重整化，但我不知道如何测试这种理论。

我们都有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

Answer 1

我发现有两种情况会发生这种情况：

• 线路结尾以及Git尝试处理跨平台的所有疯狂选项。 （我自己并不使用这些功能，而且我更喜欢存储和处理所有具有一致LF行结尾的文件，包括在Windows上。）

• 具有两个或多个文件的存储库，其名称仅在大小写上有所不同。例如，readme.txt和ReadMe.txt。 Windows上的Git很难处理这些情况，因为只有一个底层文件可以通过两个不同的名称访问。

Answer 2

Never set core.autocrlf to true, always to false。

就是这么简单：它是一个全球性的环境，会产生意想不到的后果。

如果您想要根据eol管理某些类型的文档，请仅通过.gitattributes files和core.eol directives进行管理。

这意味着：首先摆脱所有目录自动更改eol（如您的* text=auto），将该修改推回到上游仓库，然后查看问题是否仍然存在。

然后，只有这样，重新引入这些指令，而不是每个文件（不适用于'*'），但仅限于您绝对希望eol标准化的文件。
并检查是否有效。