linux - 可以在跨操作系统网络共享上使用 git 吗？

Question

我们有一些工作流程，我们希望使用安装在 NFS 网络共享上的 git 存储库。这通常效果很好，但行尾除外。显然，Linux 和 Windows 上的行结尾不同，因此 CentOS 主机上的 git status 可能显示没有任何变化，而 Windows 上同一目录中的 git status 显示所有文件修改后。

是否可以配置任何处理行尾的各种 git 机制来支持这种情况？当然，我们只希望在我们的存储库中使用 Unix 样式的行结尾，我们并不真正关心 Windows SEEING Unix 行结尾，但有时，Windows 工具会添加或意外转换文件，然后我们不想用这些结尾 checkin 。

Answer 1

这里有几个可能的解决方案。最佳解决方案取决于您是否关心工作树中的结尾。

如果您总是希望存储库中的行尾为 LF，并且您不关心工作树，则可以在存储库的 .gitattributes 文件中设置以下内容(创建它如果它不存在):

* text=auto

这将使 Git 猜测给定文件是二进制文件还是文本文件，如果是文本文件，它将在 check out 时执行转换为正确的行结尾。在 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 checkout 它们时，它们都会以适当的结尾 checkout 。这不会阻止 Windows 工具使用 CRLF 行结尾弄脏存储库，但如果它们不小心这样做，则只会 checkin LF 结尾。