使用 Git 处理 CRLF(回车、换行)的策略是什么? [英] What's the strategy for handling CRLF (carriage return, line feed) with Git?
问题描述
我尝试以 CRLF 结尾的行提交文件，但失败了.
I tried committing files with CRLF-ending lines, but it failed.
我花了一整天的时间在我的 Windows 计算机上尝试不同的策略，几乎被吸引停止尝试使用 Git 而是尝试 Mercurial.
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.
如何正确处理 CRLF 行尾?
How to properly handle CRLF line endings?
推荐答案
在提出这个问题将近四年后，我终于找到一个让我完全满意的答案！
Almost four years after asking this question, I have finally found an answer that completely satisfies me!
在 github:help 的指南中查看详细信息处理行尾.
See the details in github:help's guide to Dealing with line endings.
Git 允许您设置行结束属性repo 直接使用 text 属性.gitattributes 文件.这个文件被提交到repo 并覆盖 core.autocrlf 设置，允许您确保所有人的行为一致用户不管他们的 git 设置如何.
Git allows you to set the line ending properties for a repo directly using the text attribute in the
.gitattributesfile. This file is committed into the repo and overrides thecore.autocrlfsetting, allowing you to ensure consistent behaviour for all users regardless of their git settings.
因此
这样做的好处是你的行尾配置现在随您的存储库和您一起移动无需担心是否有合作者有适当的全局设置.
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.
这是一个 .gitattributes 文件的示例
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
有一个方便的即用型 .gitattributes 文件集合，适用于最流行的编程语言.这对您入门很有帮助.
There is a convenient collection of ready to use .gitattributes files for 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.
请注意，GitHub Desktop 应用可以建议并创建 .gitattributes在应用程序中打开项目的 Git 存储库后.要尝试此操作，请单击齿轮图标(在右上角)> 存储库设置 ... > 行尾和属性.系统会要求您添加推荐的 .gitattributes，如果您同意，该应用还将对存储库中的所有文件执行规范化.
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.
最后，注意行尾文章提供更多背景知识并解释 Git 是如何演变的关于手头的事情.我认为这是必读的.
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.
您的团队中可能有用户使用 EGit 或 JGit(Eclipse 和 TeamCity 等工具使用它们)来提交他们的更改.那么你就不走运了，正如@gatinueta 在这个答案的评论中所解释的:
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 的人，此设置将无法完全满足您，因为这些工具将忽略 .gitattributes 并愉快地检入 CRLF 文件 https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
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
一个技巧可能是让他们在另一个客户端提交他们的更改，比如 SourceTree.在许多用例中，我们的团队当时更喜欢该工具而不是 Eclipse 的 EGit.
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.
谁说软件简单?:-/
这篇关于使用 Git 处理 CRLF(回车、换行)的策略是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
