惊天大坑，快禁用Git换行符自动转换功能

引子

最近在做一个老项目的二次开发，使用的是一个国外的Pass平台。就在昨天遇到一个非常奇葩的问题，差点让我怀疑人生，事情是这样的…

有一个代码文件我做了一点简单的更改，部署上去验证时，发现前端请求后台时请求的地址不对， 我仔细查看了代码发现请求地址是通过一个公共函数获取的，我根本没动过那个函数，这不科学啊。改了好一会儿实在没头绪，我干脆把我代码备份以下，直接通过git还原到我修改之前的状态，再部署，还是不行，呀呵，见鬼了？？

然后我直接切换到master分支，再部署，依然不行。。。阿西吧

只能逼我出绝招了，我让北京的同事也部署一下master上的那代码，本来没报多大希望，结果，竟然一切正常。。。

然后我又让跟我同在郑州办公室的同事部署，跟我一样的问题。。。

这说明什么？ 一样的代码北京那边部署没问题，郑州这边部署就有问题？？？

我对天发誓，我从git上检出代码后即便什么都不修改，直接部署也不行啊！！

干了十几年开发，这种问题还真是头一遭，毫无头绪，问了几个以前的同事，也都没什么好主意。

转机

看看时间天色已晚，虽然心有不甘，但也只能先回家了。 顺带说一声，我办公室的电脑是windows系统的，家里还有一台Mac系统的Mac mini主机，吃晚饭时，突然想到，既然现在也没啥头绪，我何不用家里这台电脑试一下呢？

说干就干，马上用家里这台电脑检出代码，部署，刷新页面，天呐， 竟然好了！！！

接近真相

第二天到办公室，再次尝试部署，依然不行。。。

在排除了网络相关的问题后，凭着多年的编程的敏锐直觉，我猜想会不会跟换行符有关？ 打开VS Code，右下角确实是Windows系统的CRLF（对应Windows系统的\r\n），于是，我在VS Code种手动将这个代码文件切换成Unix的LF格式，再部署， 果然好了！！！

原来搞了半天是换行符的问题！

但是很快我又有个问题， 为啥北京那边的同事也是用的Windows电脑，他部署就没有问题，我们的代码都是直接从gitlab上拉取的，理论上代码应该是一样的，很快我向他求证后得知，他的VS Code中文件换行符格式都是LF，怪不得！

然后我就上网搜索VS Code设置全局换行符格式，后来设置完发现也没效果，它设置的貌似是创建新文件时的格式，对已有文件是没有效果的。

到这里我又冒出来一个疑问，既然北京同事本地开发环境换行符是LF，为啥他提交到gitlab上的文件是CRLF呢？

会不会是git在检出到本地时自动给我转换了换行符的格式呢？？

你还别说，经过一番搜索，狗日的，还真是git自作聪明给我转换格式了。

git有个选项autocrlf，当设置为true（windows系统上默认就是true）时，git在pull，fetch代码到本地时，会自动将文件转换为CRLF格式以兼容Windows系统，在push到远程仓库时，自动将格式转换成LF格式，保证代码仓库中文件对Unix、Mac和Windows系统都兼容。

所以，我们gitlab代码仓库中的代码格式是没有问题的，而我检查到本地的代码会自动变成CRLF，我将代码从本地部署到服务器时，就会引发问题了。

解决方案

既然真凶找到了，解决就简单了。

打开命令行执行下面两条命令：

git config --global core.autocrlf false
git config --global core.safecrlf false

如果你用了小乌龟，更简单了：

至此，圆满解决！ 真是活到老学到老。。。