针对不同环境的团队的git autocrlf管理

时间:2013-09-11 03:53:09

标签: git core.autocrlf

刚搬到git并遇到了一个问题,详细讨论了here

我想理解,因为我们默认设置了core.autocrlf = true,并且我们处理了大量的java i / o,因此有相同的测试用例;我们怎样才能确保dev on win开发的单元测试用例可以正确地为linux上的dev执行,反之亦然。

例如。单元测试用例读入文本文件(* .ext)并比较预期的字节长度与实际的长度 然后胜利; 使用core.autocrlf = true的git pull将拉入文本文件并将所有LF转换为CRLF。 例如,考虑测试用例对字节数感兴趣,因此在win上字节数会更多。 在提交时,CRLF将转换为LF;但是对于Linux上的开发人员而言测试失败了。

这可以用.gitattributes管理吗?

在.gitattributes中 - > * .ext text

这会在提交时规范化文件并仍然会遇到上述问题吗? 指针欢迎, 提前致谢

1 个答案:

答案 0 :(得分:1)

正如我之前所说,never set core.autocrlf to true, always to false

这是一个具有意想不到后果的全球环境。

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

在您的情况下,gitattributes是一个很好的解决方案,可以对您想要转换的内容进行细粒度控制。

但一般的想法是在绝对必要之前不要转换任何东西:
如果您可以使用正确的eol生成或存储这些文本文件(用于测试)(无论底层操作系统是什么),您的测试用例将是一致的。