Git diff 换行符问题
背景
由于一些特殊的原因，目前代码是运行在windows上的，开发是在mac上，但上传的代码库里的文件里的换行符却是有windows下的也有linux下的，为了保证代码的正常运行，就没敢批量的替换，统一所有文件的换行符。
问题
windows运行代码，mac下开发，从仓库检出的代码修改完后，照例执行git diff查看下差异，发现整个文件内容都修改了，于是经过一番查证，有了今天这篇记录。
原因
在Windows上编程，可能会在某个时候遇到行尾问题。这是因为Windows文件中的换行符同时使用回车符和换行符，而macOS和Linux系统只使用换行符。Windows上的许多编辑器用CRLF地替换现有的LF风格的行结尾，或者在用户点击Enter键时插入两行结束字符。
由于不同的系统之间的换行符不同，windows换行符是CRLF，而linux下是LF，这样就导致由于换行符的不同，git diff查看差异的时候整个文件都被修改了。
那么与git又有什么关系呢，是这样的，我们从远程仓库拉下来代码，比如我的，检出的时候是CRLF，然而我在地修改完代码后，本地是mac系统，是以LF为换行符的，这个时候编辑器就帮我改成了LF换行符（也可以自己手动设置换行符），这个时候我在用git diff 查看的时候自然就是整个文件内容都被修改了。
而当我忽略问题，添加到暂存区的时候则发生了一条警告如下（当然，如果你选择使用编辑器修改换行符后，自然也不会存在这条警告了）：
╭─[email protected] ~/project/okrie/printer-web ‹test*›
╰─➤ git add .
fatal: 文件 common/classes/log.php 中的 LF 将被 CRLF 替换
这个警告是说，编辑器给我改成了LF换行符后，在添加到暂存区的时候，git会自动帮我转回我检出代码时的换行符。那么为什么会有这样一个提示呢？
这与core.autocrlf和core.safecrlf 以及 core.eol这三个配置有关系。
core.autocrlf
git可以自动将CRLF行尾转换为LF，如果在Windows系统上，core.autocrlf设置为true，就可以在检出代码的时候将LF结尾转换为CRLF，提交的时候转为LF。（我们平常写代码的是我们的工作区，但我们运行git add 的时候是添加到暂存区，最后提交的时候把暂存区的内容转换为LF，而不是修改工作区的内容。但检出代码的时候是把仓库里的代码转换为CRLF到我们的工作区）
╭─[email protected] ~/project/okrie/printer-web ‹test*›
╰─➤ git config --global core.autocrlf true
如果在使用LF的Linux or macOS，检出代码的时候不希望自动转换，但是如果有意外的文件带进了CRLF，那么你肯定希望可以修复它，这个时候就可以设置core.autocrlf为input，意思就是检出代码的时候不用转换，提交的时候转换为LF。
╭─[email protected] ~/project/okrie/printer-web ‹test*›
╰─➤ git config --global core.autocrlf input
如果设置了false，这个设置应该会在Windows签出中留下CRLF结尾，但在macOS和Linux系统以及存储库中会留下LF结尾。
如果开发和运行都是windows系统，那么可以关闭此功能，通过将配置值设置为false在存储库中记录回车，但如果你运行的环境是windows，但开发是linux，那修改文件后，编辑器会帮你自动更改换行符就出问题了。
╭─[email protected] ~/project/okrie/printer-web ‹test*›
╰─➤ git config --global core.autocrlf false
core.safecrlf [参考官方文档][https://git-scm.com/docs/git-config]
如果设置为true（不是true忽略这个参数），git会检查CRLF转换是否正常，如果不正常则给一个警告， 怎么才是不正常的呢，如果core.autocrlf=true，那么我们检出代码到工作区的文件都应该是CRLF，如果工作区的文件有LF就会给一个警告，还有git也拒绝提交混合换行符的文件。git在低版本中只是一个警告，但还是可以提交的，但高版本直接就不让提交了。
CRLF转换有可能损坏数据。启用后，Git将在提交期间将CRLF转换为LF，在签出期间将LF转换为CRLF。但是Git无法重新创建在提交之前包含LF和CRLF的混合文件。对于文本文件，这是正确的做法：它更正了行尾，这样我们在存储库中只有LF行尾。但对于意外分类为文本的二进制文件，转换可能会损坏数据。可以通过在.gittattributes中显式设置转换类型来轻松地修复它。但对于，清理带有混合行尾的文本文件的预期效果和损坏二进制文件的预期效果无法区分。在这两种情况下，CRLF都以不可逆的方式被移除，对于文本文件，这是正确的做法，因为CRLFs是行尾，而对于二进制文件，转换CRLF会损坏数据。
core.eol
设置要在工作目录中用于标记为文本的文件的行尾类型（通过设置text属性，或通过设置text=auto和Git auto将内容检测为文本）。值是lf、crlf和native。默认native，即使用平台的。如果core.autocrlf设置为true或input，则忽略此值。
.gittattributes [参考1][https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings][参考2][https://git-scm.com/docs/gitattributes]
结论
- 如果工作区是mac/linux就别设置core.autocrlf了，这个东西是给windows用的，比如有人用windows开发，就可以设置为true，这样他提交的时候转化为lf，始终保持仓库里的代码是统一的换行符。
- 如果你不幸跟我一样仓库的代码里的换行符都不统一，那只能想办法把仓库里的文件换行符统一了，但这可能会带来风险。如果不想统一就保持原状，那么在linux下本地用编辑器修改带有crlf文件的，就要在修改完后把换行符改为crlf后再提交，注意中文的编码，因为编辑器会自动把我们工作区改为lf，否则这样git diff 出现的还是会是整个文件修改，但这并不是好办法。
- 也可以简单直接win下也用lf，设置一个.editorconfig文件，设置换行符号为lf，然后设置core.autocrlf为false，不过同样不能解决仓库里代码换行符不一致的情况，这个可以利用编辑器把所有的换行符更换下，这个需要你的编辑器有支持的插件，[参考][https://editorconfig.org/]。
- 具体的换行符是哪个，可以利用notepad++查看。视图-显示符号-显示所有文件符号，即可。