我尝试使用CRLF结束行提交文件,但失败了。

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

每个答案只能分享一个最佳实践。


#1楼

在提出这个问题差不多四年后,我终于找到了一个完全满足我的答案

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

Git允许您使用.gitattributes文件中的text属性直接设置repo的行结束属性。 此文件将提交到repo并覆盖core.autocrlf设置,允许您确保所有用户的行为一致,无论其git设置如何。

因此

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

这是一个.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

对于最流行的编程语言,有一个方便的即用型.gitattributes文件集合 。 让你入门是有用的。

一旦创建或调整了.gitattributes ,就应该执行一次又一次的所有行结束重新规范化 。

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

最后, Mind the End of Your Line文章提供了更多背景知识,并解释了Git如何在手头的事情上发展。 我认为这需要阅读

您的团队中可能有用户使用EGit或JGit(Eclipse和TeamCity等工具使用它们)来提交更改。 然后你运气不好,正如@gatinueta在这个答案的评论中解释的那样:

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

一个技巧可能是让他们在另一个客户端提交他们的更改,比如SourceTree 。 然后我们的团队更喜欢Eclipse的EGit工具,用于许多用例。

谁说软件很简单? : - /


#2楼

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

下面的一些附加背景:

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

上面的段落最初是从gmane.org上的一个帖子中提取出来的,但它已经失败了。


#3楼

在混合环境中(Microsoft + Linux + Mac) 获得关于行尾的一致性的两种替代策略:

A.全局所有存储库设置

1)将所有转换为一种格式

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

2)将core.autocrlf设置为在Linux / UNIX上input或在MS Windows上设置为true (存储库或全局)

git config --global core.autocrlf input

3)[可选]将core.safecrlf设置为true (停止)或warn (唱歌:)以添加额外的保护比较,如果反向换行转换将导致相同的文件

git config --global core.safecrlf true

B.或每个存储库设置

1)将所有转换为一种格式

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

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

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

不要担心你的二进制文件--Git应该足够聪明。


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


#4楼

这只是一种解决方案:

在正常情况下,请使用随git一起提供的解决方案。 这些在大多数情况下都很有效。 如果您通过设置.gitattributes在基于Windows和Unix的系统上共享开发,则强制为LF。

在我的案例中,有超过10名程序员在Windows中开发项目。 该项目已通过CRLF签入,并且没有强制选择LF的选项。

有些设置在我的机器上内部写入,对LF格式没有任何影响; 因此,在每次小文件更改时,一些文件全局更改为LF。

我的解决方案

Windows机器:让一切都按原样。 什么都不关心,因为你是一个默认的Windows'孤狼'开发者,你必须像这样处理:“广阔的世界里没有其他系统,是吗?”

Unix的机

  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 

#5楼

不要转换行结尾。 解释数据并不是VCS的工作 - 只需存储和版本化即可。 无论如何,每个现代文本编辑器都可以读取两种行结尾。


#6楼

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

实际上它听起来像core.safecrlf可能已经在您的存储库中设置,因为(强调我的):

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

如果是这种情况,那么您可能需要检查文本编辑器是否配置为始终使用行结尾。 如果文本文件包含LF和CRLF行结尾的混合,则可能会遇到问题。

最后,我觉得简单地“使用你给你的东西”并在Windows上使用LF终止线的建议将导致比它解决的更多问题。 Git有以上选项来尝试以合理的方式处理行结尾,因此使用它们是有意义的。


#7楼

这些是与MacLinux用户共享代码的WindowsVisual Studio用户的两个选项。 有关扩展说明,请阅读gitattributes手册 。

* text = auto

在您的repo的.gitattributes文件中添加:

*   text=auto

这将标准化repo中具有LF行结尾的所有文件。

根据您的操作系统( core.eol设置),工作树中的文件将针对基于Unix的系统或针对Windows系统的CRLF标准化为LF

这是Microsoft .NET repos使用的配置。

例:

Hello\r\nWorld

将在回购中标准化为:

Hello\nWorld

在结帐时,Windows中的工作树将转换为:

Hello\r\nWorld

结帐时,Mac中的工作树将保留为:

Hello\nWorld

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

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行结尾的文件引入repo。
  • 大多数Mac用户使用autocrlf = input并且可能获得具有CRLF文件结尾的文件,可能来自具有core.autocrlf = false Windows用户。

#8楼

我花了好几个小时来最好地使用 .gitattributes ,最终意识到,我不能指望它。 不幸的是,只要存在基于JGit的编辑器(无法正确处理 .gitattributes ),安全的解决方案就是在编辑器级别强制执行LF。

使用以下 anti-CRLF消毒剂。

  • windows / linux客户端: core.autocrlf=input

  • 已提交.gitattributes* text=auto eol=lf

  • 提交.editorconfig ( http://editorconfig.org/ )这是一种标准化格式,结合编辑器插件:

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

---更新2 ---

git客户端的dafaults在大多数情况下都可以使用。 即使你只有windows客户端,linux只有客户端或两者兼而有之。 这些是:

  • windows: core.autocrlf=true表示在结帐时将行转换为CRLF,并在添加文件时将行转换为LF。
  • linux: core.autocrlf=input意味着不要在checkout上转换行(不需要因为文件应该用LF提交)并在添加文件时将行转换为LF(如果需要)。

该属性可以设置在不同的范围内。 我建议明确设置--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

另外我强烈反对使用git config --global core.autocrlf false (如果你只有windows客户端)与git文档的建议形成对比。 设置为false将在repo中提交具有CRLF的文件。 但实际上没有理由。 你永远不知道是否需要与linux用户共享项目。 此外,对于加入项目而不是使用默认值的每个客户端,这是一个额外的步骤。

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

总结一下, 最佳做法是:

  • 确保在git repo上使用LF提交每个非二进制文件(默认行为)。
  • 使用此命令确保没有使用CRLF提交文件: git grep -I --files-with-matches --perl-regexp '\\r' HEAD注意:在Windows客户端上只能通过git-bash和linux工作)客户端只有在./configure使用--with-libpcre编译时才会使用。
  • 如果通过执行上述命令找到任何此类文件,请更正它们。
  • 仅使用最小的.gitattributes
  • 指示用户将上述core.autocrlf设置为其默认值。
  • 不要因为.gitattributes的存在而100% .gitattributes 。 IDE的git-clients可能会忽略它们或对它们进行不同的处理。

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

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

我认为.gitattributes其他一些安全选项,而不是使用二进制文件的自动检测:

  • -text (例如*.zip*.jpg文件:不会被视为文本。因此不会尝试行结束转换。可能通过转换程序可以实现Diff)
  • text !eol (例如,对于*.java*.html :作为文本处理,但未设置eol样式首选项。因此使用客户端设置。)
  • -text -diff -merge (例如*.hugefile :不作为文本处理。不能进行差异/合并)

---上一次更新---

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

netbeans 8.2 (在Windows上)将错误地使用CRLF提交所有文本文件,除非您已将core.autocrlf 明确设置为全局 。 这与标准的git客户端行为相矛盾,并且在更新/合并时会导致很多问题。 这使得某些文件看起来不同 (尽管它们不是), 即使你还原也是如此
即使您已将正确的.gitattributes添加到项目中,netbeans中也会出现相同的行为。

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


#9楼

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

我想底线是找到适合您环境的CRLF设置。 特别是因为在Linux盒子上的许多其他存储库中设置autocrlf = true会产生更好的结果。

20多年后,我们仍在处理操作系统之间的线路结束差异......很难过。

Git最好的CRLF(回车,换行)处理策略是什么?相关推荐

  1. 回车换行符 crlf 那点事

    不同的操作系统回车换行符定义是不一样的,如果你跟我一样记不住,crlf几个字段的含义的话,记录下来就非常有必要了 win        \r\n  CRLF ASCII 13 carriage ret ...

  2. git多系统协作时换行符问题

    为什么80%的码农都做不了架构师?>>>    --原文出自http://git.oschina.net/progit/7-%E8%87%AA%E5%AE%9A%E4%B9%89-G ...

  3. LF将由git中的CRLF替换-那是什么,它很重要吗? [重复]

    本文翻译自:LF will be replaced by CRLF in git - What is that and is it important? [duplicate] Possible Du ...

  4. git 乱改你的换行符?一句话设置让 git 不再碰你某个文件的换行符

    前些天有位小伙伴告诉我说 git 改了某个重要文件的换行符,导致文件的哈希变了,于是文件校验出现错误.之前一直没问题而最近才有问题是因为最近换了部署服务器,git 的换行符配置不一样. 其实,我们不应 ...

  5. windows下回车换行符在Linux下显示^M问题

    背景: win下的PHP文件打包,在Linux下解压后,在git status 时,显示发生修改,但并没有修改,查看文件会发现这种字符^M其实就是因为换行符的原因 ,Windows换行符和Linux换 ...

  6. html字符串自动加回车换行,【HTML】处理br换行符追加到前端换行无效的问题 --- html中渲染的字符串中包含HTML标签无效的处理方法,字符串中包含HTML标签被转义的问题 解决...

    需求如下图: 追加给前台后,效果如下: 可以在源码看到: 是将后台给出来的数据,直接当作字符串给填充在了前台HTML中. 而查看浏览器编译后的HTML源码可以发现: 原来字符串中的 的<> ...

  7. Git - 什么是 CRLF 和 LF

    是什么? 每次按键盘上的 回车 按键时,会插入一个称为行结束符的不可见字符.不同操作系统处理行结束符的方式不同. CRLF:回车换行(carriage return/line feed) LF:换行( ...

  8. 【转载】 C++中回车换行(\n\r)和换行(\r)的区别

    原文:http://blog.csdn.net/xiaofei2010/article/details/8458605 windows下的点一下回车,效果是:回车换行,就是\r\n unix系统下的回 ...

  9. VB.NET回车/换行组合符

    成员 常量 等效 说明 CrLf vbCrLf Chr(13) + Chr(10) 回车/换行组合符. Cr vbCr Chr(13) 回车符. Lf vbLf Chr(10) 换行符. NewLin ...

  10. 如何使用notepad++查看和替换回车换行符

    如何使用notepad++查看和替换回车换行符 听语音 | 浏览:178 | 更新:2018-05-25 05:16 | 标签:操作系统 1 2 3 4 5 6 7 分步阅读 有时候我们有特别的需求就 ...

最新文章

  1. java B2B2C 源码 多级分销Springcloud多租户电子商城系统(十)用spring Restdocs创建API文档...
  2. 旺苍电子计算机培训学校,广元旺苍技工学校
  3. 建立PHP-FPM的Chroot执行环境
  4. python csv读取-Python读取csv文件(详解版,看了无师自通)
  5. 网络最大流(SAP)模板
  6. Angular 使用 Injector API 人工获取依赖注入的实例
  7. 一个查看 SAP UI5 控件所有公有方法的小技巧
  8. 毕业与计算机专业,电子与计算机工程专业毕业后干什么
  9. html5 动态 menuitem,利用HTML 5中的Menu和Menuitem元素快速创建菜单
  10. jQuery 增加 删除 修改select option
  11. 分布式系统架构简单介绍
  12. 数据挖掘:针对小样本与不均衡样本的机器学习算法实践
  13. SCSI硬盘数据如何用EasyRecovery恢复
  14. java反序加密_对java程序加密防止反编译
  15. Python修改图片尺寸、裁剪图片、拼接图片
  16. 利用matlab将三维数据画成三维立体图
  17. MSP430-流水灯和key
  18. html邮件怎么发送邮件,HTML邮件怎么发送邮件
  19. 0019-python学习笔记:竞技模型
  20. 2022年-年度规划-个人家庭篇

热门文章

  1. marmalade android 5.0 JNI 调用失败的解决方案
  2. ASP.NET Web API 配置 JSONP
  3. Delphi中常用字符串处理函数
  4. ISA Server 2004服务器发布DHCP服务器
  5. [JSOI2009]球队收益
  6. Unity C# 设计模式(五)建造者模式
  7. 机器学习基石笔记-Lecture 14 Regularization
  8. 统计一个字符串中英文字母、空格、数字和其它字符的个数
  9. 求平均值 Avg.java
  10. Nginx服务安全加固