Git 的最佳 CRLF（回车、换行）处理策略是什么？

What's the best CRLF (carriage return, line feed) handling strategy with Git?

提问by Daniel Jomphe

I tried committing files with CRLF-ending lines, but it failed.

我尝试使用 CRLF 结尾的行提交文件，但它失败了。

I spent a whole work day on my Windows computer trying different strategies and was almost drawn to stop trying to use Git and instead try Mercurial.

我花了一整天的时间在我的 Windows 计算机上尝试不同的策略，几乎被吸引停止尝试使用 Git，而是尝试使用Mercurial。

Please share only one best practice per answer.

请在每个答案中只分享一个最佳实践。

回答by Daniel Jomphe

Almost four years after asking this question, I have finally found an answer that completely satisfies me!

问这个问题快四年了，我终于找到了一个完全让我满意的答案！

See the details in github:help's guide to Dealing with line endings.

请参阅github:help处理行尾的指南中 的详细信息。

Git allows you to set the line ending properties for a repo directly using the text attributein the .gitattributesfile. This file is committed into the repo and overrides the core.autocrlfsetting, allowing you to ensure consistent behaviour for all users regardless of their git settings.

Git的允许您设置为结束直接使用回购性质的行文本属性中 .gitattributes的文件。该文件被提交到 repo 并覆盖core.autocrlf设置，允许您确保所有用户的行为一致，而不管他们的 git 设置如何。

And thus

因此

The advantage of this is that your end of line configuration now travels with your repository and you don't need to worry about whether or not collaborators have the proper global settings.

这样做的好处是您的行尾配置现在随您的存储库一起移动，您无需担心协作者是否具有正确的全局设置。

Here's an example of a .gitattributesfile

这是一个.gitattributes文件示例

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

There is a convenient collection of ready to use .gitattributes filesfor the most popular programming languages. It's useful to get you started.

对于最流行的编程语言，有一个方便的即用型 .gitattributes 文件集合。这对您入门很有用。

Once you've created or adjusted your .gitattributes, you should perform a once-and-for-all line endings re-normalization.

一旦您创建或调整了您的.gitattributes，您应该执行一次一劳永逸的行尾重新规范化。

Note that the GitHub Desktopapp can suggest and create a .gitattributesfile after you open your project's Git repo in the app. To try that, click the gear icon (in the upper right corner) > Repository settings ... > Line endings and attributes. You will be asked to add the recommended .gitattributesand if you agree, the app will also perform a normalization of all the files in your repository.

请注意，在应用程序中打开项目的 Git 存储库后，GitHub 桌面应用程序可以建议并创建.gitattributes文件。要尝试此操作，请单击齿轮图标（在右上角）> 存储库设置 ... > 行尾和属性。您将被要求添加推荐的.gitattributes，如果您同意，该应用程序还将对您存储库中的所有文件执行规范化。

Finally, the Mind the End of Your Linearticle provides more background and explains how Git has evolved on the matters at hand. I consider this required reading.

最后，Mind the End of Your Line文章提供了更多背景知识，并解释了 Git 如何在手头的问题上发展。我认为这是必读的。

You've probably got users in your team who use EGit or JGit (tools like Eclipse and TeamCity use them) to commit their changes. Then you're out of luck, as @gatinueta explained in this answer's comments:

您的团队中可能有一些用户使用 EGit 或 JGit（Eclipse 和 TeamCity 等工具使用它们）来提交他们的更改。那么你就不走运了，正如@gatinueta 在这个答案的评论中所解释的那样：

This setting will not satisfy you completely if you have people working with Egit or JGit in your team, since those tools will just ignore .gitattributes and happily check in CRLF files https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

如果您的团队中有使用 Egit 或 JGit 的人，此设置将不会完全满足您，因为这些工具将忽略 .gitattributes 并愉快地检查 CRLF 文件https://bugs.eclipse.org/bugs/show_bug.cgi?编号=342372

One trick might be to have them commit their changes in another client, say SourceTree. Our team back then preferred that tool to Eclipse's EGit for many use cases.

SourceTree说，一个技巧可能是让他们在另一个客户端提交他们的更改。对于许多用例，我们的团队当时更喜欢该工具而不是 Eclipse 的 EGit。

Who said software is easy? :-/

谁说软件简单？:-/

回答by John Millikin

Don't convert line endings. It's not the VCS's job to interpret data -- just store and version it. Every modern text editor can read both kinds of line endings anyway.

不要转换行尾。解释数据不是 VCS 的工作——只是存储和版本化它。无论如何，每个现代文本编辑器都可以读取两种类型的行尾。

回答by Cory

You almost always want autocrlf=inputunless you really know what you are doing.

你几乎总是想要，autocrlf=input除非你真的知道你在做什么。

Some additional context below:

下面的一些附加上下文：

It should be either core.autocrlf=trueif you like DOS ending or core.autocrlf=inputif you prefer unix-newlines. In both cases, your Git repository will have only LF, which is the Right Thing. The only argument for core.autocrlf=falsewas that automatic heuristic may incorrectly detect some binary as text and then your tile will be corrupted. So, core.safecrlfoption was introduced to warn a user if a irreversable change happens. In fact, there are two possibilities of irreversable changes -- mixed line-ending in text file, in this normalization is desirable, so this warning can be ignored, or (very unlikely) that Git incorrectly detected your binary file as text. Then you need to use attributes to tell Git that this file is binary.

core.autocrlf=true如果您喜欢 DOS 结尾，或者core.autocrlf=input您更喜欢 unix-newlines ，那么它应该是。在这两种情况下，您的 Git 存储库都将只有 LF，这是正确的。唯一的论点core.autocrlf=false是自动启发式可能会错误地将某些二进制文件检测为文本，然后您的磁贴将被损坏。因此， core.safecrlf引入了选项以在发生不可逆转的更改时警告用户。事实上，不可逆转的变化有两种可能性——文本文件中的混合行尾，在这种规范化中是可取的，因此可以忽略此警告，或者（极不可能）Git 错误地将二进制文件检测为文本。然后你需要使用属性来告诉 Git 这个文件是二进制的。

The above paragraph was originally pulled from a thread on gmane.org, but it has since gone down.

上一段最初是从 gmane.org 上的一个帖子中提取的，但此后已被删除。

回答by lukmdo

Two alternative strategies to get consistentabout line-endings in mixed environments (Microsoft + Linux + Mac):

在混合环境（Microsoft + Linux + Mac）中保持行尾一致的两种替代策略：

A. Global per All Repositories Setup

A. Global per All Repositories Setup

1) Convert all to one format

1)全部转换为一种格式

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Set core.autocrlfto inputon Linux/UNIX or trueon MS Windows (repository or global)

2）设置core.autocrlf到input在Linux / UNIX或true在MS Windows（库或全球）

git config --global core.autocrlf input

3) [ Optional ] set core.safecrlfto true(to stop) or warn(to sing:) to add extra guard comparing if the reversed newline transformation would result in the same file

3) [ Optional ] 设置core.safecrlf为true(to stop) 或warn(to sing:) 以添加额外的保护比较反向换行转换是否会导致相同的文件

git config --global core.safecrlf true

B. Or per Repository Setup

B. 或每个存储库设置

1) Convert all to one format

1)全部转换为一种格式

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) add .gitattributesfile to your repository

2）将.gitattributes文件添加到您的存储库

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Don't worry about your binary files - Git should be smart enough about them.

不要担心你的二进制文件——Git 应该对它们足够聪明。

---

---

More about safecrlf/autocrlf variables

有关 safecrlf/autocrlf 变量的更多信息

回答by Lance Cleveland

Using core.autocrlf=falsestopped all the files from being marked updated as soon as I checked them out in my Visual Studio 2010project. The other two members of the development team are also using Windows systems so a mixed environment didn't come into play, yet the default settings that came with the repository always marked all files as updated immediately after cloning.

core.autocrlf=false一旦我在我的Visual Studio 2010项目中检出所有文件，使用就会停止所有文件被标记为更新。开发团队的另外两名成员也使用 Windows 系统，因此混合环境没有发挥作用，但存储库附带的默认设置总是在克隆后立即将所有文件标记为更新。

I guess the bottom line is to find what CRLF setting works for your environment. Especially since in many other repositories on our Linux boxes setting autocrlf = trueproduces better results.

我想最重要的是找到适合您的环境的 CRLF 设置。特别是因为在我们的 Linux 机器上的许多其他存储库中，设置autocrlf = true会产生更好的结果。

20+ years later and we're still dealing with line ending disparities between OSes... sad.

20 多年后，我们仍在处理操作系统之间的行结束差异……可悲。

回答by Greg Hewgill

Try setting the core.autocrlfconfiguration option to true. Also have a look at the core.safecrlfoption.

尝试将core.autocrlf配置选项设置为true. 也看看core.safecrlf选项。

Actually it sounds like core.safecrlfmight already be set in your repository, because (emphasis mine):

实际上听起来core.safecrlf可能已经在您的存储库中设置，因为（强调我的）：

If this is not the case for the current setting of core.autocrlf, git will reject the file.

如果 core.autocrlf 的当前设置不是这种情况，git 将拒绝该文件。

If this is the case, then you might want to check that your text editor is configured to use line endings consistently. You will likely run into problems if a text file contains a mixture of LF and CRLF line endings.

如果是这种情况，那么您可能需要检查您的文本编辑器是否配置为一致地使用行尾。如果文本文件包含 LF 和 CRLF 行尾，您可能会遇到问题。

Finally, I feel that the recommendation to simply "use what you're given" and use LF terminated lines on Windows will cause more problems than it solves. Git has the above options to try to handle line endings in a sensible way, so it makes sense to use them.

最后，我觉得在 Windows 上简单地“使用你所给的”并使用 LF 终止行的建议会导致更多的问题，而不是它解决的问题。Git 具有上述选项来尝试以合理的方式处理行尾，因此使用它们是有意义的。

回答by kiewic

These are the two options for Windowsand Visual Studiousers that share code with Macor Linuxusers. For an extended explanation, read the gitattributes manual.

这是Windows和Visual Studio用户与Mac或Linux用户共享代码的两个选项。有关扩展说明，请阅读gitattributes 手册。

* text=auto

* 文字=自动

In your repo's .gitattributesfile add:

在您的回购.gitattributes文件中添加：

*   text=auto

This will normalize all the files with LFline endings in the repo.

这将规范化所有LF在 repo 中以行结尾的文件。

And depending on your operating system (core.eolsetting), files in the working tree will be normalized to LFfor Unix based systems or CRLFfor Windows systems.

并且根据您的操作系统（core.eol设置），工作树中的文件将被标准化LF为基于 Unix 的系统或CRLFWindows 系统。

This is the configuration that Microsoft .NETrepos use.

这是Microsoft .NET 存储库使用的配置。

Example:

例子：

Hello\r\nWorld

Will be normalized in the repo always as:

将在 repo 中始终标准化为：

Hello\nWorld

On checkout, the working tree in Windows will be converted to:

结帐时，Windows 中的工作树将转换为：

Hello\r\nWorld

On checkout, the working tree in Mac will be left as:

结帐时，Mac 中的工作树将保留为：

Hello\nWorld

Note: If your repo already contains files not normalized, git statuswill show these files as completely modified the next time you make any change on them, and it could be a pain for other users to merge their changes later. See refreshing a repository after changing line endingsfor more information.

注意：如果您的 repo 已经包含未规范化的git status文件，则下次您对它们进行任何更改时，这些文件将显示为完全修改，并且其他用户稍后合并他们的更改可能会很痛苦。有关更多信息，请参阅更改行结尾后刷新存储库。

core.autocrlf = true

core.autocrlf = 真

If textis unspecified in the .gitattributesfile, Git uses the core.autocrlfconfiguration variable to determine if the file should be converted.

如果text在.gitattributes文件中未指定，Git 使用core.autocrlf配置变量来确定是否应该转换文件。

For Windows users, git config --global core.autocrlf trueis a great option because:

对于 Windows 用户，这git config --global core.autocrlf true是一个不错的选择，因为：

• Files are normalized to LFline endings only when addedto the repo. If there are files not normalized in the repo, this setting will not touch them.
• All text files are converted to CRLFline endings in the working directory.

• 文件仅在添加到 repo时才被规范化为LF行尾。如果 repo 中存在未规范化的文件，则此设置不会触及它们。
• 所有文本文件都转换为CRLF工作目录中的行尾。

The problem with this approach is that:

这种方法的问题在于：

• If you are a Windows user with autocrlf = input, you will see a bunch of files with LFline endings. Not a hazard for the rest of the team, because your commits will still be normalized with LFline endings.
• If you are a Windows user with core.autocrlf = false, you will see a bunch of files with LFline endings and you may introduce files with CRLFline endings into the repo.
• Most Mac users use autocrlf = inputand may get files with CRLFfile endings, probably from Windows users with core.autocrlf = false.

• 如果您是使用 的 Windows 用户autocrlf = input，您将看到一堆带有LF行结尾的文件。对团队的其他成员来说不是危险，因为您的提交仍将使用LF行尾进行规范化。
• 如果您是使用 的 Windows 用户core.autocrlf = false，您将看到一堆带有LF行尾的文件，并且您可以将带有CRLF行尾的文件引入到 repo 中。
• 大多数 Mac 用户使用autocrlf = input并且可能会获得带有CRLF文件结尾的文件，可能来自带有core.autocrlf = false.

回答by Marinos An

--- UPDATE 3 --- (does not conflict with UPDATE 2)

--- 更新 3 ---（与更新 2 不冲突）

Considering the case that windows users prefer working on CRLFand linux/mac users prefer working on LFon text files. Providing the answer from the perspective of a repository maintainer:

考虑到 Windows 用户更喜欢处理CRLF而 linux/mac 用户更喜欢处理LF文本文件的情况。从存储库维护者的角度提供答案：

For me the best strategy(less problems to solve) is: keep all text fileswith LFinside git repoeven if you are working on a windows-only project. Then give the freedom to clientsto work on the line-ending style of their preference, provided that they pick a core.autocrlfproperty value that will respect your strategy (LF on repo)while staging files for commit.

对我来说，最好的策略（少的问题解决）是：保留所有文本文件与LF内部的git回购，即使你是一个只有Windows的项目。然后让客户可以自由地使用他们喜欢的行尾样式，前提是他们选择了一个core.autocrlf属性值，该值将在暂存文件以提交提交时尊重您的策略（存储库中的 LF）。

Stagingis what many people confuse when trying to understandhow newline strategieswork. It is essential to undestand the following points before picking the correct value for core.autocrlfproperty:

分期是许多人在尝试了解换行策略如何工作时所混淆的。在选择正确的core.autocrlf财产价值之前，必须先了解以下几点：

• Adding a text file for commit (stagingit) is like copying the file to another placeinside .git/sub-directory with converted line-endings(depending on core.autocrlfvalue on your client config). All this is done locally.
• setting core.autocrlfis like providing an answer to the question (exact same question on all OS):
  • "Should git-client a.convert LF-to-CRLF when checking-out (pulling) the repo changes from the remoteor b.convert CRLF-to-LF when adding a file for commit?" and the possible answers (values) are:
  • false:"do noneof the above",
  • input:"do only b"
  • true: "do a and and b"
  • note that there is NO "do only a"

• 增加对提交（文本文件分期的话）是一样的文件复制到另一个地方，里面.git/的子目录与转换行结束（取决于core.autocrlf值在客户端的配置）。所有这些都是在本地完成的。
• 设置core.autocrlf就像提供问题的答案（所有操作系统上的问题完全相同）：
  • “git-client a.是否应该在从远程检出（拉取）repo 更改时将 LF 转换为 CRLF或b.在添加提交文件时将 CRLF 转换为 LF？”以及可能的答案（值）是：
  • false:“以上都不做”，
  • input:“不仅有B”
  • true：“做a和b”
  • 请注意，没有“只做一个”

Fortunately

幸运的是

• git client defaults (windows: core.autocrlf: true, linux/mac: core.autocrlf: false) will be compatible with LF-only-repostrategy.
  Meaning: windows clients will by default convert to CRLF when checking-out the repository and convert to LF when adding for commit. And linux clients will by default not do any conversions. This theoretically keeps your repo lf-only.

• git 客户端默认值 (windows: core.autocrlf: true, linux/mac: core.autocrlf: false) 将与LF-only-repo策略兼容。
  含义：默认情况下，Windows 客户端在检出存储库时将转换为 CRLF，并在添加提交时转换为 LF。并且 linux 客户端默认不会进行任何转换。从理论上讲，这只会使您的回购保持不变。

Unfortunately:

很遗憾：

• There might be GUI clients that do not respect the git core.autocrlfvalue
• There might be people that don't use a value to respect your lf-repo strategy. E.g. they use core.autocrlf=falseand add a file with CRLF for commit.

• 可能存在不尊重 gitcore.autocrlf值的GUI 客户端
• 可能有些人不使用价值来尊重您的 lf-repo 策略。例如，他们使用core.autocrlf=false并添加一个带有 CRLF 的文件进行提交。

To detect ASAP non-lf text files committed by the above clientsyou can follow what is described on --- update 2 ---: (git grep -I --files-with-matches --perl-regexp '\r' HEAD, on a client compiled using: --with-libpcreflag)

要检测由上述客户端提交的 ASAP 非 lf 文本文件，您可以按照 --- update 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD，在使用：--with-libpcre标志编译的客户端上）

And here is the catch:. I as a repo maintainer keep a git.autocrlf=inputso that I can fix any wrongly committed files just by adding them again for commit. And I provide a commit text: "Fixing wrongly committed files".

这是问题所在：。作为 repo 维护者git.autocrlf=input，我保留了一个，这样我就可以通过再次添加提交来修复任何错误提交的文件。我提供了一个提交文本：“修复错误提交的文件”。

As far as .gitattributesis concearned. I do not count on it, because there are more ui clients that do not understand it. I only use it to provide hints for text and binary files, and maybe flag some exceptional files that should everywhere keep the same line-endings:

至于.gitattributes被concearned。我不指望它，因为有更多的 ui 客户端不了解它。我只用它来为文本和二进制文件提供提示，并且可能会标记一些应该到处保持相同行尾的特殊文件：

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Question: But why are we interested at all in newline handling strategy?

问题：但是为什么我们对换行处理策略感兴趣呢？

Answer:To avoid a single letter change commit, appear as a 5000-line change, just because the client that performed the change auto-converted the full file from crlf to lf (or the opposite) before adding it for commit. This can be rather painfulwhen there is a conflict resolutioninvolved. Or it could in some cases be the cause of unreasonable conflicts.

回答：为了避免单个字母更改提交，显示为 5000 行更改，因为执行更改的客户端在添加提交之前自动将完整文件从 crlf 转换为 lf（或相反）。当涉及解决冲突时，这可能会相当痛苦。或者在某些情况下它可能是不合理冲突的原因。

---

---

--- UPDATE 2 ---

--- 更新 2 ---

The dafaults of git client will work in most cases. Even if you only have windows only clients, linux only clients or both. These are:

git 客户端的 dafaults 将在大多数情况下工作。即使您只有 Windows 客户端、Linux 客户端或两者兼而有之。这些是：

• windows:core.autocrlf=truemeans convert lines to CRLF on checkout and convert lines to LF when adding files.
• linux:core.autocrlf=inputmeans don't convert lines on checkout (no need to since files are expected to be committed with LF) and convert lines to LF (if needed) when adding files. (-- update3 --: Seems that this is falseby default, but again it is fine)

• windows：core.autocrlf=true表示在结账时将行转换为 CRLF，在添加文件时将行转换为 LF。
• linux:core.autocrlf=input意味着不要在结帐时转换行（不需要，因为文件应该与 LF 一起提交）并在添加文件时将行转换为 LF（如果需要）。( -- update3 --: 似乎这是false默认的，但还是可以的)

The property can be set in different scopes. I would suggest explicitly setting in the --globalscope, to avoid some IDE issues described at the end.

该属性可以设置在不同的范围内。我建议明确设置--global范围，以避免最后描述的一些 IDE 问题。

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Also I would strongly discourageusing on windowsgit config --global core.autocrlf false(in case you have windows only clients) in contrast to what is proposed togit documentation. Setting to false will commit files with CRLF in the repo. But there is really no reason. You never know whether you will need to share the project with linux users. Plus it's one extra step for each client that joins the project instead of using defaults.

此外，我强烈反对在 Windows 上使用git config --global core.autocrlf false（如果您只有 Windows 客户端）与git 文档中的建议相反。设置为 false 将在 repo 中提交带有 CRLF 的文件。但真的没有理由。您永远不知道是否需要与 linux 用户共享该项目。另外，对于加入项目而不是使用默认值的每个客户来说，这是一个额外的步骤。

Now for some special cases of files (e.g. *.bat*.sh) which you want them to be checked-out with LF or with CRLF you can use .gitattributes

现在对于某些特殊情况的文件（例如*.bat*.sh），您希望它们使用 LF 或 CRLF 检出，您可以使用.gitattributes

To sum-up for me the best practiceis:

总结一下，最佳实践是：

• Make sure that every non-binary file is committed with LF on git repo (default behaviour).
• Use this command to make sure that no files are committed with CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD(Note:on windows clients works only through git-bashand on linux clients only if compiled using --with-libpcrein ./configure).
• If you find any such files by executing the above command, correct them. This in involves (at least on linux):
  • set core.autocrlf=input(--- update 3 --)
  • change the file
  • revert the change(file is still shown as changed)
  • commit it
• Use only the bare minimum .gitattributes
• Instruct the users to set the core.autocrlfdescribed above to its default values.
• Do not count 100% on the presence of .gitattributes. git-clients of IDEs may ignore them or treat them differrently.

• 确保在 git repo 上使用 LF 提交每个非二进制文件（默认行为）。
• 使用此命令以确保没有文件承诺与CRLF： git grep -I --files-with-matches --perl-regexp '\r' HEAD（注：在Windows客户端只有通过工作git-bash和Linux客户端仅在使用编译--with-libpcre中./configure）。
• 如果您通过执行上述命令找到任何此类文件，请更正它们。这涉及（至少在 linux 上）：
  • 设置core.autocrlf=input( --- 更新 3 --)
  • 更改文件
  • 恢复更改（文件仍显示为已更改）
  • 提交它
• 仅使用最低限度 .gitattributes
• 指示用户core.autocrlf将上述内容设置为其默认值。
• 不要 100% 计算.gitattributes. IDE 的 git-clients 可能会忽略它们或以不同的方式对待它们。

As said some things can be added in git attributes:

如上所述，可以在 git 属性中添加一些内容：

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

I think some other safe options for .gitattributesinstead of using auto-detection for binary files:

我认为其他一些安全选项可以.gitattributes代替对二进制文件使用自动检测：

• -text(e.g for *.zipor *.jpgfiles: Will not be treated as text. Thus no line-ending conversions will be attempted. Diff might be possible through conversion programs)
• text !eol(e.g. for *.java,*.html: Treated as text, but eol style preference is not set. So client setting is used.)
• -text -diff -merge(e.g for *.hugefile: Not treated as text. No diff/merge possible)

• -text（例如 for*.zip或*.jpgfiles：不会被视为文本。因此不会尝试行结束转换。通过转换程序可能会有差异）
• text !eol（例如 for *.java, *.html: 视为文本，但未设置 eol 样式首选项。因此使用客户端设置。）
• -text -diff -merge（例如*.hugefile：不被视为文本。没有差异/合并可能）

--- PREVIOUS UPDATE ---

--- 以前的更新 ---

One painful exampleof a client that will commit files wrongly:

一个客户端错误提交文件的痛苦例子：

netbeans 8.2(on windows), will wrongly commit all text files with CRLFs, unlessyou have explicitlyset core.autocrlfas global. This contradicts to the standard git client behaviour, and causes lots of problems later, while updating/merging. This is what makes some files appear different(although they are not) even when you revert.
The same behaviour in netbeans happens even if you have added correct .gitattributesto your project.

netbeans 8.2（在 Windows 上）将错误地提交所有带有CRLF 的文本文件，除非您已明确设置core.autocrlf为 global。这与标准的 git 客户端行为相矛盾，并在以后更新/合并时导致很多问题。这就是使某些 文件看起来不同（尽管它们不是）的原因，即使您将.
即使您.gitattributes在项目中添加了正确的内容，netbeans 中也会发生相同的行为。

Using the following command after a commit, will at least help you detect early whether your git repo has line ending issues: git grep -I --files-with-matches --perl-regexp '\r' HEAD

在提交后使用以下命令，至少可以帮助您及早检测您的 git repo 是否有行结束问题： git grep -I --files-with-matches --perl-regexp '\r' HEAD

I have spent hours to come up with the best possible use of .gitattributes, to finally realize, that I cannot count on it.
Unfortunately, as long as JGit-based editors exist (which cannot handle .gitattributescorrectly), the safe solution is to force LF everywhere even on editor-level.

我花了几个小时想出最好的 使用方法.gitattributes，最终意识到，我不能指望它。
不幸的是，只要基于 JGit 的编辑器存在（无法.gitattributes正确处理），安全的解决方案就是在任何地方强制使用 LF，即使在编辑器级别也是如此。

Use the following anti-CRLFdisinfectants.

使用以下anti-CRLF消毒剂。

• windows/linux clients: core.autocrlf=input

• committed .gitattributes: * text=auto eol=lf

• committed .editorconfig(http://editorconfig.org/) which is kind of standardized format, combined with editor plugins:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

• Windows/Linux 客户端： core.autocrlf=input

• 承诺.gitattributes： * text=auto eol=lf

• 提交.editorconfig（http://editorconfig.org/）这是一种标准化格式，结合编辑器插件：

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

回答by John Rumpel

This is just a workaroundsolution:

这只是一个变通的解决方案：

In normal cases, use the solutions that are shipped with git. These work great in most cases. Force to LF if you share the development on Windows and Unix based systems by setting .gitattributes.

通常情况下，使用 git 附带的解决方案。这些在大多数情况下都很好用。如果您通过设置.gitattributes在基于 Windows 和 Unix 的系统上共享开发，则强制使用 LF 。

In my case there were >10 programmers developing a project in Windows. This project was checked in with CRLF and there was no option to force to LF.

就我而言，有超过 10 名程序员在 Windows 中开发一个项目。这个项目是用 CRLF 签入的，没有强制执行 LF 的选项。

Some settings were internally written on my machine without any influence on the LF format; thus some files were globally changed to LF on each small file change.

一些设置是在我的机器上内部编写的，对 LF 格式没有任何影响；因此，每次小文件更改时，某些文件都会全局更改为 LF。

My solution:

我的解决方案：

Windows-Machines:Let everything as it is. Care about nothing, since you are a default windows 'lone wolf' developer and you have to handle like this: "There is no other system in the wide world, is it?"

Windows-Machines：让一切照原样。什么都不在乎，既然你是一个默认的 windows '孤狼' 开发者，你必须像这样处理：“世界上没有其他系统，是吗？”

Unix-Machines

Unix-机器

1. Add following lines to a config's [alias]section. This command lists all changed (i.e. modified/new) files:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "
   

2. Convert all those changedfiles into dos format:

   unix2dos $(git lc)
   

3. Optionally ...

   1. Create a git hookfor this action to automate this process

   2. Use params and include it and modify the grepfunction to match only particular filenames, e.g.:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
      

   3. Feel free to make it even more convenient by using an additional shortcut:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "
      

      ... and fire the converted stuff by typing

      git c2dos
      

1. 将以下行添加到配置[alias]部分。此命令列出所有更改的（即修改的/新的）文件：

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "
   

2. 将所有这些更改的文件转换为 dos 格式：

   unix2dos $(git lc)
   

3. 可选...

   1. 为此操作创建一个 git hook以自动执行此过程

   2. 使用 params 并包含它并修改grep函数以仅匹配特定的文件名，例如：

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
      

   3. 随意使用额外的快捷方式使其更加方便：

      c2dos = "!f() { unix2dos $(git lc) ; }; f "
      

      ...并通过键入来触发转换后的内容

      git c2dos