Git中的AutoCRLF与SafeCRLF换行符问题

最近在使用GitHub,发现不时没有修改过的文件要提交,对比发现文件全部修改,但找不到不一样的地方。想可能是换行符的问题,因为Windows和Linux的换行符不一样,而Git默认应该是Linux的,今天Bing了下,果然是这个问题。

CR回车 LF换行Windows/Dos CRLF \r\n
Linux/Unix LF \n
MacOS CR \r
解决方法是:打开命令行,进行设置,如果你是在Windows下开发,建议设置autocrlf为true。2014/08/20 补充:如果你文件编码是UTF8并且包含中文文字,那还是把autocrlf设置为false,并且把所有文件转换为Linux编码(即LF\n),开启safecrlf检查。
一、AutoCRLF
#提交时转换为LF,检出时转换为CRLF
git config --global core.autocrlf true   

#提交时转换为LF,检出时不转换
git config --global core.autocrlf input   

#提交检出均不转换
git config --global core.autocrlf false

二、SafeCRLF

#拒绝提交包含混合换行符的文件
git config --global core.safecrlf true   

#允许提交包含混合换行符的文件
git config --global core.safecrlf false   

#提交包含混合换行符的文件时给出警告
git config --global core.safecrlf warn
时间: 2025-01-02 15:48:16

Git中的AutoCRLF与SafeCRLF换行符问题的相关文章

git在window与linux的换行符问题

1:背景.我win7,后端是win10,使用了TortoiseGit工具.我使用ssh,他使用http.仓库是在linux,使用gitLab管理 2:问题.仓库是总监之前建好的.后端把文件add后push,我clone本地后没有放进编辑器中也没有做任何的修改,马上commit,提示所有文件已修改,打开对比了,只是结尾的换行有修改 3:差异.因为之前没有遇到过这样的问题,不知从何下手,刚开始以为是编码问题,百度谷歌后不知所以然,就从编码到git版本用排除法一一对比,最后发现我们2个人的连接方式不一

git中配置autocrlf来正确处理crlf

在使用git的过程中,如果我们的项目是跨平台开发的 那么CRLF的处理也许会成为一个很头疼的事情,有可能会出以下的莫名其妙的问题: 我们的某个开发人员在linux上提交的一个文件, 当从windows上pull下来后,没做任何的修改,查看其status,它的状态已经是modifed了 即使你使用git checkout -f来恢复改文件,它的状态仍然是modified,真是郁闷… 后来,才发现就是CRLF惹的祸. 我们都知道,在Windows上是CRLF来作为一行的结束符,而Linux上则是LF

将文本文件中的\n字符串变成换行符

1.用notepad打开文件 2.查看换行符,不同操作系统的换行符是不同的. [视图]--[显示符号]--[显示行尾符]. 我的操作系统是windows,所以行尾符是CR LF--对应的正则表达式是\r\n. mac系统是CR--对应的正则表达式是\r. unix系统是LF--对应的正则表达式是\n 3.替换操作 快捷键Ctrl+H,[查找目标]输入[\\n],替换成[\r\n],如下图所示. 注意选中正则表达式,查找文字要转义,如[\n]要写成[\\n] 4.结果如下  字符串[\n]全部变成

Git中CRLF与LF的转换

1.换行符在不同的操作系统上的表示 首先要理解的一点是,对于不同的操作系统,对于换行符的表示是不一样的.也就是说当我们在编辑一个文件,在键盘上按下回车键的时候,对于不同的操作系统保存到文件中的换行符是不一样的.见下表: CR:表示回车\r LF:表示换行\n CRLF:表示回车换行\r\n 敲下回车键,不同的操作系统保存到文件中的值: Windows:使用的是CRLF ==> 即\r\n,文件中保存的是\r\n Linux/Unix: 使用的是LF ==> 即\n,文件中保存的是\n Mac

小小换行符乱谈(文本文件vs二进制文件)

使用 C 语言的 fopen 打开文件时,可以指定的 mode 有 12 个,其中 6 个包含  "b" 使用 C++ 的 fstream 打开文件时,可用的模式组合有 24 个(?),其中 12 个包含  "binary" 使用 python 的 open 打开文件,除了可以使用 C 中的 12 个模式外,还可以使用  "U" 或 "rU" 使用 Qt 库的 QFile 打开文件时,可以指定  QIODevice::Text

【工具使用】sublime设置换行符为unix风格

windows下sublime写的代码,换行符为/r/n,python代码转移到centos上执行老是出问题 通过自定义settings-user中default_line_endings则可以修改换行符风格,详细设置如下两图

Git坑换行符自动转换 [转载]

转自https://www.cnblogs.com/zjoch/p/5400251.html 源起 一直想在 GitHub 上发布项目.参与项目,但 Git 这货比较难学啊.买了一本<Git 权威指南>,翻了几页,妈呀,那叫一个复杂,又是 Cygwin 又是命令行的,吓得我不敢学了. 终于某天发现 GitHub 还有一个 Windows 客户端,试了一下还挺好用.不需要掌握太多的 Git 原理和命令,也可以在 GitHub 上麻溜建项目了,甚是欢喜.可是好景不长,第一次参与开源项目就出洋相了.

git 自动转换行符的坑爹案例

本人写的脚本都是在unix上运行的,但是编写有时候喜欢使用Git拉去到windows的ide进行编写,毕竟我的unix只有命令行的没有ide, 殊不知有一天我的sh执行时出现错误 -bash: ./dailytask.sh: /bin/sh^M: bad interpreter: 没有那个文件或目录 使用vim的命令:set ff?来查看文件格式发现已经是dos,修改格式为unix,命令如下:set ff=unix 接着再运行就好了 如果文件很多都修改成dos格式了,请示用dos2unix来进行

有关git的换行符的处理问题

签入签出时对换行符的操作: #签出时将LF转换为CRLF,签入时将CRLF转换为LF git config --global core.autocrlf true #签出时不转换,签入时转换为LF git config --global core.autocrlf input #签入签出均不转换(推荐这种,还原事实,保留真相) git config --global core.autocrlf false 包含混合换行符时的操作: #包含混合换行符时拒绝提交(推荐这种,乱乱的换行符坑队友啊) g