Git 处理 CRLF(回车、换行)的策略是什么?
我尝试提交以 CRLF 结尾的行的文件,但失败了。
我花了一整天的时间在我的 Windows 计算机上尝试不同的策略,并且几乎被吸引停止尝试使用 Git,而是尝试 水银。
如何正确处理 CRLF 行结尾?
I tried committing files with CRLF-ending lines, but it failed.
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.
How to properly handle CRLF line endings?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(9)
在问这个问题近四年后,我终于
找到一个完全令我满意的答案!
请参阅 github:help 指南中的详细信息
处理行结尾。
因此
这是
.gitattributes
文件的示例有一个方便的现成使用的集合。最流行的编程语言的 gitattributes 文件。 这对您入门很有用。
创建或调整
.gitattributes
后,您应该执行一劳永逸的 行尾重新规范化。请注意,GitHub Desktop 应用程序可以在您选择后建议并创建一个
.gitattributes
文件在应用程序中打开项目的 Git 存储库。 要尝试此操作,请单击齿轮图标(位于右上角)> 存储库设置...>> 行结束符和属性。 系统会要求您添加推荐的.gitattributes
,如果您同意,该应用程序还将对存储库中的所有文件执行规范化。最后,注意行尾一文
提供更多背景知识并解释 Git 的演变过程
关于手头的事情。 我认为这是必读的内容。
您的团队中可能有用户使用 EGit 或 JGit(Eclipse 和 TeamCity 等工具使用它们)来提交更改。 那么你就不走运了,正如 @gatinueta 在这个答案的评论中解释的那样:
一个技巧可能是让他们在另一个客户端中提交更改,例如 SourceTree。 对于许多用例,我们的团队当时更喜欢该工具,而不是 Eclipse 的 Egit。
谁说软件很简单? :-/
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.
And thus
Here's an example of a
.gitattributes
fileThere is a convenient collection of ready to use .gitattributes files for the most popular programming languages. It's useful to get you started.
Once you've created or adjusted your
.gitattributes
, you should perform a once-and-for-all line endings re-normalization.Note that the GitHub Desktop app can suggest and create a
.gitattributes
file 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.gitattributes
and if you agree, the app will also perform a normalization of all the files in your repository.Finally, the Mind the End of Your Line article
provides more background and explains how Git has evolved
on the matters at hand. I consider this required reading.
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:
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.
Who said software is easy? :-/
不要转换行结尾。 VCS 的工作不是解释数据,而是存储数据并对其进行版本控制。 无论如何,每个现代文本编辑器都可以读取这两种行结尾。
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.
除非您真的知道自己在做什么,否则您几乎总是需要
autocrlf=input
。下面是一些附加上下文:
上面的段落最初是从 gmane.org 上的一个帖子中提取的,但后来它已经被删除了。
You almost always want
autocrlf=input
unless you really know what you are doing.Some additional context below:
The above paragraph was originally pulled from a thread on gmane.org, but it has since gone down.
在混合环境(Microsoft + Linux + Mac)中保持行尾一致的两种替代策略:
A. 全局 所有存储库设置
转换全部为一种格式
在 Linux/UNIX 上将
core.autocrlf
设置为input
或在 MS Windows(存储库或全局)上设置true
(可选)将
core.safecrlf
设置为true
(停止)或warn
(唱歌:)以添加额外的保护来比较反向换行符转换将产生相同的文件B. 或每个存储库设置
将全部转换为一种格式
将
.gitattributes
文件添加到您的存储库不要担心您的二进制文件 - Git 应该对它们足够聪明。
有关 safecrlf/autocrlf 变量的更多信息
Two alternative strategies to get consistent about line-endings in mixed environments (Microsoft + Linux + Mac):
A. Global All Repositories Setup
Convert all to one format
Set
core.autocrlf
toinput
on Linux/UNIX ortrue
on MS Windows (repository or global)Optionally, set
core.safecrlf
totrue
(to stop) orwarn
(to sing:) to add extra guard comparing if the reversed newline transformation would result in the same fileB. Or per Repository Setup
Convert all to one format
Add a
.gitattributes
file to your repositoryDon't worry about your binary files—Git should be smart enough about them.
More about safecrlf/autocrlf variables
--- UPDATE 3 --- (与 UPDATE 2 不冲突)
考虑到 Windows 用户更喜欢在
CRLF
上工作,而 linux/mac 用户更喜欢在LF
上工作文本文件。 从存储库维护者的角度提供答案:对我来说,最佳策略(需要解决的问题较少)是:保留所有文本文件即使您正在处理仅限 Windows 的项目,
LF
inside git repo 也是如此。 然后,给予客户自由,让他们可以使用他们偏好的行结束样式,前提是他们选择的core.autocrlf
属性值符合以下条件:在暂存文件以供提交时将尊重您的策略(LF on repo)。分期是许多人在试图理解换行策略如何工作时感到困惑的地方。 在为
core.autocrlf
属性选择正确的值之前,必须了解以下几点:.git/
子目录中的另一个位置,并带有转换后的行尾(取决于您的core.autocrlf
值)客户端配置)。 所有这些都是在本地完成的。core.autocrlf
就像为问题提供答案(在所有操作系统上都完全相同):“应该git 客户端:false:
“不执行上述任何操作”,输入:
“只做b”true
:“执行a 和 b”幸运的是
core.autocrlf: true
, linux/mac:core.autocrlf: false
) 将与 LF-only-repo 策略兼容。含义:Windows 客户端在签出存储库时默认会转换为 CRLF,在添加提交时会默认转换为 LF。 Linux 客户端默认不会进行任何转换。 从理论上讲,这只会使您的存储库保持在 lf 状态。
不幸的是:
core.autocrlf
值要尽快检测上述客户端提交的非 lf 文本文件,您可以按照 --- update 2 --- 中的描述进行操作:(
git grep -I --files-with-匹配 --perl-regexp '\r' HEAD
,在使用--with-libpcre
标志编译的客户端上)这里是问题:。 作为仓库维护者,我保留了一个 git.autocrlf=input ,这样我就可以通过再次添加它们进行提交来修复任何错误提交的文件。 我提供了一个提交文本:“修复错误提交的文件”。
就
.gitattributes
而言。 我不指望它,因为有更多的 ui 客户端不理解它。 我只用它来提供文本和二进制文件的提示,并且可能标记一些应该在各处保持相同行结尾的特殊文件:问题:但是为什么我们对换行处理策略感兴趣?
答案:为了避免单字母更改提交,显示为 5000 行更改,只是因为执行更改的客户端自动将整个文件从 crlf 转换为 lf (或相反)在添加它进行提交之前。 当涉及冲突解决时,这可能会相当痛苦。 或者在某些情况下它可能成为不合理冲突的原因。
--- 更新 2 ---
git 客户端的默认设置在大多数情况下都可以工作。 即使您只有 Windows 客户端、Linux 客户端或两者都有。 它们是:
core.autocrlf=true
表示在签出时将行转换为 CRLF,在添加文件时将行转换为 LF。core.autocrlf=input
表示在签出时不转换行(不需要,因为文件预计以 LF 提交)并将行转换为 LF(如果添加文件时需要)。(-- update3 --:默认情况下似乎这是
false
,但同样没问题)该属性可以在不同的范围内设置。 我建议在
--global
范围中显式设置,以避免最后描述的一些 IDE 问题。另外,我强烈不鼓励在Windows上使用
git config --global core.autocrlf false
(如果您只有Windows客户端)与提议的内容相反 git 文档。 设置为 false 将在存储库中提交带有 CRLF 的文件。 但确实没有理由。 您永远不知道是否需要与 Linux 用户共享该项目。 另外,对于加入该项目的每个客户来说,这是一个额外的步骤,而不是使用默认值。现在,对于某些特殊情况的文件(例如
*.bat
*.sh
),您希望使用 LF 或 CRLF 检出它们,您可以使用.gitattributes
对我来说,最佳实践是:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
(注意: 在 Windows 客户端上只能通过git-bash
工作,在 Linux 客户端上只有在./configure
中使用--with-libpcre
编译时才有效) 。core.autocrlf=input
(---更新3--).gitattributes
core.autocrlf
设置为其默认值。.gitattributes
的存在。 IDE 的 git 客户端可能会忽略它们或以不同的方式对待它们。正如所说,有些东西可以在 git 属性中添加:
我认为
.gitattributes
的其他一些安全选项而不是对二进制文件使用自动检测:-text
(例如 < code>*.zip 或*.jpg
文件:不会被视为文本,因此可能不会通过转换程序尝试进行行结束转换)。 text !eol
(例如,对于*.java
、*.html
:视为文本,但未设置 eol 样式首选项。因此使用客户端设置。 )-text -diff -merge
(例如对于*.hugefile
:不被视为文本。无法进行差异/合并)--- 上一次更新 ---
一个 错误提交文件的客户端的痛苦示例:
netbeans 8.2(在 Windows 上),将错误地使用 CRLF 提交所有文本文件,除非您有<强>显式将
core.autocrlf
设置为全局。 这与标准 git 客户端行为相矛盾,并在更新/合并时导致很多问题。 这就是为什么某些文件看起来不同(尽管事实并非如此)即使您恢复了的原因。即使您已将正确的
.gitattributes
添加到项目中,netbeans 中也会发生相同的行为。提交后使用以下命令,至少可以帮助您尽早检测 git 存储库是否存在行结束问题: git grep -I --files-with-matches --perl-regexp '\r' HEAD
我花了几个小时来想出.gitattributes
的最佳用法,最终意识到我不能指望它。不幸的是,只要基于 JGit 的编辑器存在(无法正确处理
.gitattributes
),安全的解决方案就是在任何地方强制使用 LF,甚至在编辑器级别也是如此。使用以下
抗CRLF消毒剂。
windows/linux 客户端:
core.autocrlf=input
提交的
.gitattributes
:* text=auto eol=lf
提交的
.editorconfig
(http://editorconfig.org/),这是一种标准化格式,与编辑器插件相结合:<罢工>https://github.com/welovecoding/editorconfig-netbeans/
--- UPDATE 3 --- (does not conflict with UPDATE 2)
Considering the case that windows users prefer working on
CRLF
and linux/mac users prefer working onLF
on text files. Providing the answer from the perspective of a repository maintainer:For me the best strategy(less problems to solve) is: keep all text files with
LF
inside git repo even if you are working on a windows-only project. Then give the freedom to clients to work on the line-ending style of their preference, provided that they pick acore.autocrlf
property value that will respect your strategy (LF on repo) while staging files for commit.Staging is what many people confuse when trying to understand how newline strategies work. It is essential to undestand the following points before picking the correct value for
core.autocrlf
property:.git/
sub-directory with converted line-endings (depending oncore.autocrlf
value on your client config). All this is done locally.core.autocrlf
is like providing an answer to the question (exact same question on all OS): "Should git-client:false:
"do none of the above",input:
"do only b"true
: "do a and and b"Fortunately
core.autocrlf: true
, linux/mac:core.autocrlf: false
) will be compatible with LF-only-repo strategy.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.
Unfortunately:
core.autocrlf
valuecore.autocrlf=false
and add a file with CRLF for commit.To detect ASAP non-lf text files committed by the above clients you can follow what is described on --- update 2 ---: (
git grep -I --files-with-matches --perl-regexp '\r' HEAD
, on a client compiled using:--with-libpcre
flag)And here is the catch:. I as a repo maintainer keep a
git.autocrlf=input
so 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".As far as
.gitattributes
is 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: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 painful when there is a conflict resolution involved. Or it could in some cases be the cause of unreasonable conflicts.
--- UPDATE 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:
core.autocrlf=true
means convert lines to CRLF on checkout and convert lines to LF when adding files.core.autocrlf=input
means 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
false
by default, but again it is fine)The property can be set in different scopes. I would suggest explicitly setting in the
--global
scope, to avoid some IDE issues described at the end.Also I would strongly discourage using on windows
git config --global core.autocrlf false
(in case you have windows only clients) in contrast to what is proposed to git 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.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
To sum-up for me the best practice is:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
(Note: on windows clients works only throughgit-bash
and on linux clients only if compiled using--with-libpcre
in./configure
).core.autocrlf=input
(--- update 3 --).gitattributes
core.autocrlf
described above to its default values..gitattributes
. git-clients of IDEs may ignore them or treat them differrently.As said some things can be added in git attributes:
I think some other safe options for
.gitattributes
instead of using auto-detection for binary files:-text
(e.g for*.zip
or*.jpg
files: 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)--- PREVIOUS UPDATE ---
One painful example of a client that will commit files wrongly:
netbeans 8.2 (on windows), will wrongly commit all text files with CRLFs, unless you have explicitly set
core.autocrlf
as 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
.gitattributes
to your project.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
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
.gitattributes
correctly), the safe solution is to force LF everywhere even on editor-level.Use the following
anti-CRLF
disinfectants.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/welovecoding/editorconfig-netbeans/
当我在我的 Visual Studio 2010 项目。 开发团队的另外两名成员也使用 Windows 系统,因此混合环境没有发挥作用,但存储库附带的默认设置始终将所有文件标记为在克隆后立即更新。
我想最重要的是找到适合您的环境的 CRLF 设置。 特别是因为在我们的 Linux 机器上的许多其他存储库中设置
autocrlf = true
会产生更好的结果。20 多年过去了,我们仍在处理操作系统之间的行尾差异......令人难过。
Using
core.autocrlf=false
stopped all the files from being marked updated as soon as I checked them out in my Visual Studio 2010 project. 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.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 = true
produces better results.20+ years later and we're still dealing with line ending disparities between OSes... sad.
尝试将
core.autocrlf
配置选项设置为true
。 另请查看 core.safecrlf 选项。实际上,听起来
core.safecrlf
可能已经在您的存储库中设置了,因为(强调我的):如果是这种情况,那么您可能需要检查您的文本编辑器是否配置为一致地使用行结尾。 如果文本文件包含 LF 和 CRLF 行结尾的混合,您可能会遇到问题。
最后,我认为简单地“使用你所得到的”并在 Windows 上使用 LF 终止行的建议会导致比它解决的问题更多的问题。 Git 有上述选项来尝试以合理的方式处理行结尾,因此使用它们是有意义的。
Try setting the
core.autocrlf
configuration option totrue
. Also have a look at thecore.safecrlf
option.Actually it sounds like
core.safecrlf
might already be set in your repository, because (emphasis mine):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.
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.
对于与 Mac 或 Linux 用户共享代码的 Windows 和 Visual Studio 用户来说,有两个选项。 有关详细说明,请阅读 gitattributes 手册。
* text=auto
在存储库的
.gitattributes
文件中添加:这将规范存储库中以
LF
行结尾的所有文件。根据您的操作系统(
core.eol
设置),工作树中的文件将标准化为LF
(对于基于 Unix 的系统)或CRLF
对于 Windows 系统。这是 Microsoft .NET 存储库使用的配置。
示例:
将在存储库中始终标准化为:
结帐时,Windows 中的工作树将转换为:
结帐时,Mac 中的工作树将保留为:
core.autocrlf = true
如果
.gitattributes
文件中未指定text
,Git 使用core.autocrlf
配置变量来确定该文件是否应该被转换。对于 Windows 用户,
git config --global core.autocrlf true
是一个不错的选择,因为:LF
行结尾到回购协议。 如果存储库中存在未标准化的文件,则此设置不会影响它们。CRLF
行结尾。这种方法的问题在于:
autocrlf = input
的 Windows 用户,您将看到一堆带有LF
行结尾的文件。 对于团队的其他成员来说这不是危险,因为您的提交仍将以LF
行结尾进行标准化。core.autocrlf = false
的 Windows 用户,您将看到一堆带有LF
行结尾的文件,并且您可能会引入带有CRLF
的文件code> 行结尾到存储库中。autocrlf = input
,并且可能会获取带有CRLF
文件结尾的文件,这些文件可能来自带有core.autocrlf = false
的 Windows 用户。These are the two options for Windows and Visual Studio users that share code with Mac or Linux users. For an extended explanation, read the gitattributes manual.
* text=auto
In your repo's
.gitattributes
file add:This will normalize all the files with
LF
line endings in the repo.And depending on your operating system (
core.eol
setting), files in the working tree will be normalized toLF
for Unix based systems orCRLF
for Windows systems.This is the configuration that Microsoft .NET repos use.
Example:
Will be normalized in the repo always as:
On checkout, the working tree in Windows will be converted to:
On checkout, the working tree in Mac will be left as:
core.autocrlf = true
If
text
is unspecified in the.gitattributes
file, Git uses thecore.autocrlf
configuration variable to determine if the file should be converted.For Windows users,
git config --global core.autocrlf true
is a great option because:LF
line endings only when added to the repo. If there are files not normalized in the repo, this setting will not touch them.CRLF
line endings in the working directory.The problem with this approach is that:
autocrlf = input
, you will see a bunch of files withLF
line endings. Not a hazard for the rest of the team, because your commits will still be normalized withLF
line endings.core.autocrlf = false
, you will see a bunch of files withLF
line endings and you may introduce files withCRLF
line endings into the repo.autocrlf = input
and may get files withCRLF
file endings, probably from Windows users withcore.autocrlf = false
.这只是一个解决方法解决方案:
在正常情况下,使用 git 附带的解决方案。 这些在大多数情况下都很有效。 如果您通过设置 .gitattributes 在基于 Windows 和 Unix 的系统上共享开发,则强制为 LF。
就我而言,有超过 10 名程序员在 Windows 中开发一个项目。 这个项目是用 CRLF 签入的,没有强制换成 LF 的选项。
一些设置是在我的机器上内部编写的,对 LF 格式没有任何影响; 因此,在每次小文件更改时,某些文件都会全局更改为 LF。
我的解决方案:
Windows 机器:
让一切保持原样。 无需关心任何事情,因为您是默认的 Windows“独狼”开发人员,并且您必须这样处理:“世界上没有其他系统,不是吗?”
Unix-Machines
将以下行添加到配置的
[alias]
部分。 此命令列出所有已更改(即修改/新)的文件:将所有这些已更改文件转换为 dos 格式:
可选...
为此创建一个 git 钩子自动化此过程的操作
使用参数并包含它并修改
grep
函数以仅匹配特定文件名,例如:随意使用额外的快捷方式使其更加方便:
...并通过键入来触发转换后的内容
This is just a workaround solution:
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.
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.
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.
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?"
Unix-Machines
Add following lines to a config's
[alias]
section. This command lists all changed (i.e. modified/new) files:Convert all those changed files into dos format:
Optionally ...
Create a git hook for this action to automate this process
Use params and include it and modify the
grep
function to match only particular filenames, e.g.:Feel free to make it even more convenient by using an additional shortcut:
... and fire the converted stuff by typing