什么是Git最好的CRLF（回车，换行）处理策略？ [英] What's the best CRLF (carriage return, line feed) handling strategy with Git?

问题描述

我试着用CRLF结束行提交文件，但是失败了。

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

每个答案只能分享一个最佳做法。

解决方案

在问这个问题近四年后， b $ b找到完全满足我的答案！

查看 github：help 的详细指南至
处理行结尾。

Git允许您直接使用回购的行结束属性＃b $ strong> .gitattributes中的＃_checking-out_and_checking-in> text属性 文件。这个文件被委托给
repo并且覆盖 core.autocrlf 设置，
允许您确保所有
用户的一致行为

因此

这样做的好处是，您的行尾
配置现在随存储库一起传输，您
不需要担心协作者
是否具有正确的全局设置。 / p>

以下是一个 .gitattributes 文件的示例

＃自动检测文本文件并执行LF标准化
* text = auto

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

* .csproj文本合并=联合
* .sln文本合并=联合eol = crlf

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

＃绝对路径正常，像globs
/ ** / postinst * text eol = lf
$ b不以/开头的$ b＃路径相对于.gitattributes文件夹处理
relative / path / *。txt text eol = lf


大多数方便的可随时使用.gitattributes文件的集合流行的编程语言。

一旦您创建或调整了您的 .gitattributes ，你应该执行一次又一次的行结束符重新标准化。

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

最后，关注您的线路结束文章
提供了更多背景信息，并解释了Git如何在手头上演变
。我认为这个需要阅读。

您的团队中可能有使用EGit或JGit的用户（Eclipse和TeamCity等工具使用它们）提交他们的修改。然后你运气不好，因为@gatinueta在这个答案的评论中解释道：

如果你有人，这个设置不会完全满足你在您的团队中使用Egit或JGit，因为这些工具只会忽略.gitattributes并且愉快地检查CRLF文件 https ：//bugs.eclipse.org/bugs/show_bug.cgi？id = 342372

一招可能是让他们在另一个客户端进行修改，例如 SourceTree 。我们的团队当时喜欢使用Eclipse的EGit作为许多用例。

谁说软件很简单？ ： - /

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.

Please share only one best practice per answer.

解决方案

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.

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

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 .gitattributes file

# 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 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:

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

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? :-/

这篇关于什么是Git最好的CRLF（回车，换行）处理策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！