我有代码(用C#编写(可以在Linux和Windows上运行。作为自动化构建过程的一部分，单元/集成测试在 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出现在字符串中，但由于我的约束，我无法完成此操作。
我无权访问生成代理。它需要完成工作的任何设置或值都需要在我的源代码中捕获，而不是计算机上的某个本地值。我有限的理解告诉我，我应该依赖.gitattributes文件，虽然我已经看到，甚至稍微理解了我可以在.gitattributes文件中使用的行尾周围的一些各种设置。
我不能只将 Windows 计算机配置为使用core.autocrlf=true，将 Linux 计算机配置为使用core.autocrlf=false或某些变体，除非我只能通过添加或修改存储库中包含的文件来执行此操作。
考虑到我的约束，有没有办法使用 git 完成此操作？
我不能只将Windows机器配置为使用core.autocrlf=true，而将Linux机器配置为使用core.autocrlf=false
完美，无论如何，core.autocrlf应该(几乎(始终设置为 false。
代码本身应该只是LF：它将由Windows和Linux上的IDE正确解释。
至于字符串，单元测试代码应该：
- 检测操作系统
- 根据操作系统将测试中使用的所述字符串转换为使用 LF 或 CRLF
含义：Git 与单元测试应该如何运行无关。
所述单元测试不应依赖于是否正确配置外部工具(此处为版本控制工具(。 它们应该独立于任何.gitattributes正确运行：他们的代码应该负责构建预期的结果。
默认情况下，Git 对文本文件执行行尾转换。 如果您希望文件转换其行尾，可以通过在.gitattributes文件中标记它们来将它们标记为文本：
*.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，或者根据用户的开发环境留给用户的意愿。
如果需要在测试中显式使用平台的本机行尾，则应编写一个显式字符串，该字符串将根据平台进行适当分析，或者将测试字符串包装在基于平台转换它们的帮助程序函数中。