我不理解git:core.autocrlfcore.safecrlf中CrLf设置的复杂性
我正在一个团队中开发一个跨平台的项目，希望Windows和Linux开发人员能够一起工作，而不必因为行尾样式而将文件标记为已修改.
各种设置意味着什么？ Select 任何一个选项会有什么后果？对我来说，什么是最好的解决方案？
是的，我知道有this question个，其中的答案没有深刻见解，因此没有帮助.
我不理解git:core.autocrlfcore.safecrlf中CrLf设置的复杂性
我正在一个团队中开发一个跨平台的项目，希望Windows和Linux开发人员能够一起工作，而不必因为行尾样式而将文件标记为已修改.
各种设置意味着什么？ Select 任何一个选项会有什么后果？对我来说，什么是最好的解决方案？
是的，我知道有this question个，其中的答案没有深刻见解，因此没有帮助.
autocrlf的三个值:
true-当内容进入存储库(提交)时，其行尾将转换为LF，当内容从存储库出来(签出)时，行尾将转换为CRLF.这通常是为无知的windows用户/编辑设计的.假设一个编辑(或用户)将创建带有CRLF结尾的文件，如果看到正常的LF结尾，他会发疯，但你希望在回购中使用LF结尾，这将有望涵盖你.不过，事情可能会出差错.链接问题中有虚假合并冲突和修改文件报告的例子.
input-当内容进入存储库时，其行尾将转换为LF，但内容在退出时保持不变.这基本上与true处于同一领域，前提是编辑实际上可以正确处理LF结尾；您只是在防止意外创建带有CRLF结尾的文件.
false-git根本不处理行尾.这取决于你.这是很多人推荐的.有了这个设置，如果文件的行尾会被弄乱，你必须意识到这一点，所以合并冲突的可能性要小得多(假设知情的用户).教育开发人员如何使用他们的编辑器/IDE几乎可以解决这个问题.我见过的所有为程序员设计的编辑器，如果配置正确，都能够处理这个问题.
请注意，autocrlf不会影响存储库中already的内容.如果你之前做过CRLF结尾的事情，他们会一直这样.这是避免依赖autocrlf的一个很好的理由；如果一个用户没有设置它，他们可以将带有CRLF结尾的内容输入到repo中，它会一直存在.迫使正常化的一个更有力的方法是使用text attribute；假设git决定内容是文本(而不是二进制)，那么将给定路径的值设置为auto将标记为行尾规范化.
一个相关的选项是safecrlf，这基本上只是一种确保不会对二进制文件不可逆转地执行CRLF转换的方法.
我在处理Windows问题和git方面没有太多经验，所以关于影响/trap 的反馈肯定是受欢迎的.