我们有一些工作流程，我们想使用安装在NFS网络共享上的git存储库。除行尾以外，这通常效果很好。显然，Linux和Windows上的行尾不同，因此CentOS主机上的git status可能没有显示更改，而Windows相同目录中的git status显示了所有已修改的文件。
是否可以配置用于处理行尾的各种git机制中的任何一种来支持这种情况？当然，我们只希望在仓库中使用Unix样式的行尾，并且我们并不真正在乎Windows SEEING Unix的行尾，但有时Windows工具会添加或意外转换文件，然后我们不希望使用这些结尾进行检入。
答案 0 :(得分：0)
这里有两种可能的解决方案。最好的解决方案取决于您是否关心工作树的结尾。
如果您始终希望存储库中的行尾为LF，并且您不关心工作树，则可以在存储库中的.gitattributes文件中设置以下内容（如果没有，则创建它）不存在）：
* text=auto
这将使Git猜测给定文件是二进制文件还是文本文件，如果是文本文件，它将在签出时执行转换为正确的行尾的操作。在Unix上，正确的行尾应为LF，在Windows上，通常应为CRLF（尽管您可以使用core.eol覆盖它）。
如果您始终希望对象和工作树中的行尾都为LF，那么您需要做更多的工作。您需要使用eol=lf适当地设置每个单独的文本文件类型：
*.c text eol=lf
*.h text eol=lf
之所以这样做是因为eol=lf会覆盖文本检测，这意味着将其应用于二进制文件（例如PDF或JPEG文件）并不安全。如果将其应用于存储库中的所有文件，则将损坏所有碰巧包含CRLF的二进制文件。
无论您做什么，都应先执行git add --renormalize .，然后再执行git commit。这样可以确保您存储库中的所有文件都包含LF结尾，并且每当Git检出它们时，它们都将以适当的结尾检出。但这并不能防止Windows工具弄脏带有CRLF行尾的存储库，但是如果它们偶然这样做，则只会签入LF结尾。