Git on Windows: crff 设置是什么意思？

我不理解在 git 中与 CrLf 设置相关的复杂性: core.autocrlf，core.safecrlf

我正在一个团队中开发一个跨平台项目，希望 Windows 和 Linux 开发人员能够一起工作，而不会仅仅因为行结束风格而将文件标记为已修改的 git。

What do the various settings mean? What would be the consequences of choosing any of the options? And what would be the best solution for my case?

是的，我知道 这个问题，那里的答案没有深刻的见解，因此没有帮助。

22213 次浏览
小开
最佳答案

autocrlf的三个值:

  • true - when content goes into the repository (is committed), its line endings will be converted to LF, and when content comes out of the repository (is checked out), the line endings be converted to CRLF. This is in general meant for clueless windows users/editors. Given the assumption that an editor (or user) is going to create files with CRLF endings, and will freak out if it sees normal LF endings, but that you want LF endings in the repo, this will hopefully cover you. It's possible for things to go awry, though. There are examples of spurious merge conflicts and reports of modified files in the linked questions.

  • input-当内容进入存储库时，其行结尾将被转换为 LF，但内容在退出时保持不变。这基本上与 true相同，假设编辑器实际上可以正确地处理 LF 结尾; 您只是在防止意外地创建具有 CRLF 结尾的文件的可能性。

  • false-git 根本不处理行结尾。你自己决定吧。这是很多人推荐的。有了这个设置，如果一个文件的行结尾被弄乱了，那么您必须意识到这一点，因此合并冲突的可能性要小得多(假设用户是知情的)。教育开发人员如何使用编辑器/IDE 可以很好地解决这个问题。我见过的所有为程序员设计的编辑器，如果配置正确，都能够处理这个问题。

请注意，autocrlf不会影响存储库中的 已经内容。如果你已经承诺与 CRLF 结尾以前的东西，他们将保持这种方式。这是一个非常好的理由来避免依赖 autocrlf; 如果一个用户没有设置它，他们可以将带有 CRLF 结尾的内容放入回购，并且它会一直存在。更强有力的规范化方法是使用 文本属性; 如果 git 决定内容是文本(而不是二进制) ，那么对给定路径将其设置为 auto将标记为行尾规范化。

一个相关的选项是 safecrlf，它基本上只是一种确保您不会对二进制文件执行不可逆转的 CRLF 转换的方法。

我没有大量处理 Windows 问题和 git 的经验，所以当然欢迎关于暗示/陷阱的反馈。

小开

我研究了提交和签出用例的3种可能值，得到的结果表如下:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

我建议在所有平台上使用 core.autocrlf = input。在这种情况下，如果 Git 面向 CRLF，它将隐式地将其转换为 LF，并且使用 LF的现有文件保持原样。

小开

顺便说一下，默认情况下，以 Windows 结尾的 Line 将采用 CRLF，而 Linux 将采用 LF。 请看下表以便理解。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

在上面的表格信息中，符号 * 突出了 Windows 和 Unix 之间的区别。粗略看来，以下是基于操作系统平台的 CLRF 信息:

适用于 Windows 用户

  • 如果 Windows 用户使用跨平台项目，则对于 Windows 计算机 必须的为 core.autocrlf=true，对于 Unix 计算机 core.autocrlf=input为 core.autocrlf=input。
  • If windows users work with Only Windows projects, It can be both core.autocrlf=true or core.autocrlf=false. But core.autocrlf=input will result in issues in this case.

For Unix users (Linux / Mac OS)

  • 如果 Unix 用户使用跨平台项目，则 Windows 机器的 必须的为 core.autocrlf=true，Unix 机器的 core.autocrlf=input为 core.autocrlf=input。
  • 如果 Unix 用户只使用 Unix 项目，则可以同时使用 core.autocrlf=input或 core.autocrlf=false。但在这种情况下，core.autocrlf=true将导致问题。

对于相同的操作系统用户

  • For a pure Windows project or pure Unix project, it can be core.autocrlf=false.

提交答案