Git-在Linux上使用Linux样式的行尾，在Windows上使用Windows样式的行尾

我有可以在Linux和Windows上运行的代码（用C#编写）。作为自动化构建过程的一部分，单元/集成测试在TeamCity构建机器上运行。如果进行了更改，它将触发Linux和Windows构建，并且将在Linux和Windows上执行相同的单元测试

这些构建代理使用git来下拉源代码/构建/测试

所需的行为是Linux代理的源代码使用Linux样式（LF）行结尾，而Windows代理的代码将使用Windows样式（CR LF）行结尾。原因是代码使用多行字符串文字作为某些单元测试的输入，而被测试代码使用

Environment.NewLine

var example = @"This is a really,
really long string";

在Linux和Windows中，我都希望系统定义的Environment.NewLine显示在字符串中，但由于我的限制，我无法实现这一点

我没有访问生成代理的权限。它需要执行的任何设置或值都需要在我的源代码中捕获，而不是机器上的一些本地值。我有限的理解告诉我，我应该依赖于

.gittributes

文件，虽然我已经看到了，甚至稍微了解了，我可以在

.gittributes

文件中使用的关于行尾的各种设置

我不能只将Windows机器配置为使用

core.autocrlf=true

，而将Linux机器配置为使用

core.autocrlf=false

或其他变体，除非我只能通过添加或修改存储库中包含的文件来实现

考虑到我的限制，有没有一种方法可以使用git来实现这一点

我不能只将Windows机器配置为使用core.autocrlf=true，而将Linux机器配置为使用core.autocrlf=false

完美

代码本身应该是LF-only：它将被Windows和Linux上的IDE正确解释

对于字符串，单元测试代码应：

• 检测操作系统
• 根据操作系统的不同，将测试中使用的字符串转换为LF或CRLF

意思是：Git与单元测试应该如何运行无关。
所述单元测试不应依赖于外部工具（此处为版本控制工具）是否正确配置。

---

它们应该独立于任何

而正确运行。gittributes

：它们的代码应该负责生成预期的结果。

默认情况下，Git对文本文件执行行尾转换。如果要转换文件的行尾，可以通过在

.gittributes

文件中标记它们来将其标记为文本：

*.cs text

如果您想让Git自动猜测哪些文件是文本，那么您应该编写如下内容：

* text=auto

假设构建代理没有覆盖行尾的自定义Git配置，Git应该足以将行尾转换为本机行尾。如果希望明确，可以将

core.eol

设置为

native

，这样执行克隆：

git-c core.eol=native clone URL

然而，话虽如此，在代码中对行尾进行假设通常不是一个好主意。如果您的用户正在使用针对Linux的Windows子系统，那么他们很可能正在使用Unix Git并在其工作树中使用Unix行结束符，这不应该影响单元测试的正确性。由于功能原因（例如，shell脚本在任何平台上都不能与CRLF结尾一起使用），行结尾应显式设置为LF或CRLF，或者根据用户的开发环境由用户自行决定

---

如果您需要在测试中显式使用平台的本机行结尾，您应该编写一个显式字符串，该字符串将根据平台进行适当的分析，或者将测试字符串包装在一个帮助函数中，该函数将根据平台对其进行转换。

因此，如果我理解正确的话；就跨平台开发而言，使用多行字符串文字有点反模式，因为git确实关心该字符串的内容，对吗？@RobP。git不应该关心该字符串的内容。您的单元测试代码应该关注多行字符串的内容，而不管版本控制工具在签出期间对它做了什么。这将确保跨平台的单元测试是健壮的。我真的很感激这个答案。我同意，我做了很多错事——没有统一的构建代理配置，代码/测试依赖于行尾作为本机行尾，可能还有更多。但是它听起来像是指定核心。克隆期间的EOL =原生将做我正在寻找的精确的事情，即使它是一个创伤性援助的更严重的问题。