Linux Windows 上的 Git：crlf 设置是什么意思？

Git on Windows: What do the crlf settings mean?

提问by Jonathan

I don't understand the complexities related to CrLf settings in git: core.autocrlf, core.safecrlf

我不了解有关的git的CRLF设置的复杂性：core.autocrlf，core.safecrlf

I'm developing a cross-platform project in a team and would like both Windows and Linux developers to be able to work together without git marking files as modified just because of line ending style.

我正在一个团队中开发一个跨平台项目，并且希望 Windows 和 Linux 开发人员能够一起工作，而不会因为行尾样式而将文件标记为已修改。

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?

各种设置是什么意思？选择任何一个选项会产生什么后果？对于我的情况，最好的解决方案是什么？

Yes, I'm aware of this questionand the answers there were not insightful, thus not helpful.

是的，我知道这个问题，那里的答案没有洞察力，因此没有帮助。

采纳答案by Cascabel

The three values for autocrlf:

的三个值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- when content goes into the repository, its line endings will be converted to LF, but content is left untouched on the way out. This is basically in the same realm as true, with the assumption that the editors actually can deal with LF endings correctly; you're just guarding against the possibility of accidentally creating a file with CRLF endings.

• false- git doesn't deal with line endings at all. It's up to you. This is what a lot of people recommend. With this setting, if a file's line endings are going to be messed with, you'll have to be aware of it, so merge conflicts are a lot less likely (assuming informed users). Educating developers about how to use their editors/IDEs can pretty much take care of the problem. All of the editors I've seen designed for programmers are capable of dealing with this if configured properly.

• true- 当内容进入存储库（被提交）时，其行尾将转换为 LF，当内容从存储库中出来（被检出）时，行尾将转换为 CRLF。这通常适用于无知的 Windows 用户/编辑器。假设编辑器（或用户）将创建具有 CRLF 结尾的文件，并且如果它看到正常的 LF 结尾会吓坏了，但是你想要在 repo 中使用 LF 结尾，这有望覆盖你。但是，事情可能会出错。链接问题中有虚假合并冲突和修改文件报告的示例。

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

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

Note that autocrlfwill not affect content which is alreadyin the repository. If you've committed something with CRLF endings previously, they'll stay that way. This is a very good reason to avoid depending on autocrlf; if one user doesn't have it set, they can get content with CRLF endings into the repo, and it'll stick around. A stronger way to force normalization is with the text attribute; setting it to autofor a given path will mark it for end-of-line normalization, assuming git decides the content is text (not binary).

请注意，autocrlf这不会影响存储库中已有的内容。如果您之前提交过以 CRLF 结尾的内容，它们将保持原样。这是避免依赖 autocrlf 的一个很好的理由；如果一个用户没有设置它，他们可以将带有 CRLF 结尾的内容放入 repo，并且它会保留下来。强制规范化的一种更强大的方法是使用text 属性；将其设置auto为给定路径将标记为行尾规范化，假设 git 决定内容是文本（不是二进制）。

A related option is safecrlf, which is basically just a way to make sure you don't irreversably perform CRLF conversion on a binary file.

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

I don't have a ton of experience dealing with Windows issues and git, so feedback about implications/pitfalls is certainly welcome.

我没有处理 Windows 问题和 git 的大量经验，因此当然欢迎有关影响/陷阱的反馈。

回答by pratt

I explored 3 possible values for commit and checkout cases and this is the resulting table:

我探索了提交和结帐案例的 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 ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

I would recommend to use core.autocrlf = inputacross all platforms. In this case if Git faces CRLFit will implicitly convert it into LF, and existing files with LFremain as is.

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

回答by Srikanth Popuri

FYI., By default, Line ending in Windows will take CRLF and Linux will take LF. Please find the below table for clear understanding.

仅供参考，默认情况下，以 Windows 结尾的行将采用 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 ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

In the above tabular information, the symbol * highlights the differences between Windows and Unix. At a glance, below is the CLRF information based on the OS platforms:

在上面的表格信息中，符号 * 突出了 Windows 和 Unix 之间的差异。一目了然，以下是基于OS平台的CLRF信息：

---

---

For Windows users

对于 Windows 用户

• If windows users working with cross-platform projects, It MUSTbe core.autocrlf=truefor Windows machines and core.autocrlf=inputfor Unix machines.
• If windows users work with Only Windows projects, It can be both core.autocrlf=trueor core.autocrlf=false. But core.autocrlf=inputwill result in issues in this case.

• 如果Windows用户提供跨平台项目的工作，它必须是core.autocrlf=true针对Windows机器和core.autocrlf=input用于Unix机器。
• 如果 Windows 用户仅使用 Windows 项目，则它可以是两者core.autocrlf=true或core.autocrlf=false. 但是core.autocrlf=input在这种情况下会导致问题。

---

---

For Unix users (Linux / Mac OS)

对于 Unix 用户（Linux / Mac OS）

• If Unix users working with cross-platform projects, It MUSTbe core.autocrlf=truefor Windows machines and core.autocrlf=inputfor Unix machines.
• If Unix users work with Only Unix projects, It can be both core.autocrlf=inputor core.autocrlf=false. But core.autocrlf=truewill result in issues in this case.

• 如果Unix用户跨平台项目的工作，它必须是core.autocrlf=true针对Windows机器和core.autocrlf=input用于Unix机器。
• 如果 Unix 用户使用 Only Unix 项目，它可以是 bothcore.autocrlf=input或core.autocrlf=false. 但是core.autocrlf=true在这种情况下会导致问题。

---

---

For same OS users

对于相同的操作系统用户

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

• 对于纯 Windows 项目或纯 Unix 项目，它可以是core.autocrlf=false.