LF 将被 git 中的 CRLF 取代 - 那是什么，它很重要吗？

LF will be replaced by CRLF in git - What is that and is it important?

提问by LearningRoR

When I create a new rails application I'm seeing a warning in git about LF replacement. I do git init git add .

当我创建一个新的 rails 应用程序时，我在 git 中看到一个关于 LF 替换的警告。我做 git init git add 。

and then boom! I see this pop up for almost all files. I usually just keep going and build my application and it disappears after many changes to files.

然后轰！我看到几乎所有文件都会弹出这个。我通常只是继续构建我的应用程序，并且在对文件进行多次更改后它就会消失。

Example:

例子：

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.lock.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in README.

该文件将在您的工作目录中以原始行结尾。警告：LF 将被 Gemfile 中的 CRLF 替换。

该文件将在您的工作目录中以原始行结尾。警告： LF 将被 Gemfile.lock 中的 CRLF 替换。

该文件将在您的工作目录中以原始行结尾。警告：LF 将被 README 中的 CRLF 替换。

What's the difference between LF and CRLF?

LF 和 CRLF 有什么区别？

Should I be concerned about this in the long run or just ignore it and keep going as I usually do?

从长远来看，我应该关注这个问题，还是只是忽略它并像往常一样继续前进？

回答by Shrage Smilowitz

In Unix systems the end of a line is represented with a line feed (LF). In windows a line is represented with a carriage return (CR) and a line feed (LF) thus (CRLF). when you get code from git that was uploaded from a unix system they will only have an LF.

在 Unix 系统中，行的结尾用换行符 (LF) 表示。在 Windows 中，一行用回车 (CR) 和换行 (LF) 表示 (CRLF)。当您从 git 获取从 unix 系统上传的代码时，它们将只有一个 LF。

If you are a single developer working on a windows machine, and you don't care that git automatically replaces LFs to CRLFs, you can turn this warning off by typing the following in the git command line

如果您是在 Windows 机器上工作的单个开发人员，并且您不关心 git 自动将 LF 替换为 CRLF，则可以通过在 git 命令行中键入以下内容来关闭此警告

git config core.autocrlf true

If you want to make an intelligent decision how git should handle this, read the documentation

如果你想做出明智的决定 git 应该如何处理这个问题，请阅读文档

Here is a snippet

这是一个片段

Formatting and Whitespace

Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It's very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.

core.autocrlf

If you're programming on Windows and working with people who are not (or vice-versa), you'll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you're on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true

If you're on a Linux or Mac system that uses LF line endings, then you don't want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you're a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

$ git config --global core.autocrlf false

格式和空格

格式和空格问题是许多开发人员在协作时遇到的一些更令人沮丧和微妙的问题，尤其是跨平台。补丁或其他协作工作很容易引入细微的空白更改，因为编辑器会默默地引入它们，如果您的文件曾经接触过 Windows 系统，它们的行尾可能会被替换。Git 有一些配置选项可以帮助解决这些问题。

core.autocrlf

如果您在 Windows 上编程并与非 Windows 人员一起工作（反之亦然），您可能会在某个时候遇到行尾问题。这是因为 Windows 在其文件中同时使用回车符和换行符作为换行符，而 Mac 和 Linux 系统仅使用换行符。这是跨平台工作的一个微妙但令人难以置信的烦人的事实；Windows 上的许多编辑器默默地用 CRLF 替换现有的 LF 样式行尾，或者在用户按下 Enter 键时插入两个行尾字符。

当您将文件添加到索引时，Git 可以通过将 CRLF 行结尾自动转换为 LF 来处理此问题，反之亦然，当它检出代码到您的文件系统时。您可以使用 core.autocrlf 设置打开此功能。如果您使用的是 Windows 计算机，请将其设置为 true – 这会在您检出代码时将 LF 结尾转换为 CRLF：

$ git config --global core.autocrlf true

如果您使用的是使用 LF 行结尾的 Linux 或 Mac 系统，那么您不希望 Git 在您签出文件时自动转换它们；但是，如果意外引入了带有 CRLF 结尾的文件，那么您可能需要 Git 修复它。您可以通过将 core.autocrlf 设置为输入来告诉 Git 在提交时将 CRLF 转换为 LF，而不是相反：

$ git config --global core.autocrlf input

此设置应该让您在 Windows 结帐中使用 CRLF 结尾，但在 Mac 和 Linux 系统以及存储库中使用 LF 结尾。

如果你是一个 Windows 程序员，正在做一个仅限 Windows 的项目，那么你可以关闭这个功能，通过将配置值设置为 false 来在存储库中记录回车：

$ git config --global core.autocrlf false

回答by SG 86

If you want, you can deactivate this feature in your git core config using

如果需要，您可以使用以下命令在 git 核心配置中停用此功能

git config core.autocrlf false

But it would be better to just get rid of the warnings using

但最好只是摆脱使用警告

git config core.autocrlf true