喜闻乐见的git autocrlf问题

喜闻乐见的git autocrlf问题

最近在启动一个项目的时候，突然就很莫名的报出一个秘钥签名失败，要知道作为一个菜鸟，这种配置基本都是不会自己改的，如果要改，也是和前辈确认再三才会下手，但是出现问题了，就得解决问题。
终于，在我不懈努力下，果然没有找到问题出在哪，还得看师父的。
是两个秘钥文件出现的问题，在对比了两个文件16进制内容后，自己本地的文件要比远程仓库中的文件大几K，究其原因是换行符的问题，也就是autocrlf的设置问题。
众所周知，操作系统不同，换行符也是有不同的

• windows中的换行符为crlf
• mac/unix中的换行符是lf
  远程仓库为lf，因此windows中的文件，如果上传到远程仓库中去的话，是会出现问题的，如果是Java代码的话，无伤大雅，如果是秘钥文件，任何差池都是不能有的，，因此需要做一些处理。
  core.autocrlf设置选项有：

true	Windows默认选项，如果设置为该项，push代码的时候，会将push到代码仓库的代码切换为LF，当从远处仓库pull代码的时候，会将保存到本地的代码设置为CRLF。
false	Linux下默认为该选项，即无论push还是pull代码，都不对代码的换行符进行转换。
input	如果设置为该项，push代码的时侯，会将push到代码仓库的代码切换为LF模式，当从远程代码仓库pull代码的时候，不会转换代码的换行符。

git的范围：system>global>local
优先级与范围相反，越小的环境配置参数的优先级越高
建议：
Windows系统的不用设置，使用默认选项true即可。
macOS系统建议使用input

非官方的黑话：
标准化 指在提交代码到git数据库(本地库) 中将文本文件中的换行符CRLF转为LF的过程
转换 指在检出Git数据库代码过程中将文本文件中的换行符LF转换为CRLF的过程

相比于配置core.autocrlf的值，git官方提供了更加优秀的解决方案：出处 ，待自己有空以及水平更近一部时，可以再来了解下这个配置文件的优秀之处。

gitattributes配置文件，在这个文件中可以针对一些具体类型文件做不同的处理，，并且一个项目中可以同时存在多个这样的配置文件。

感想：今晚专门花费了一定的时间，来记录下最近的问题，值得记下的问题，暂时就这两个，为了能让问题更加有说服力，也为了自己能进一步明白这写问题的本质，所以看了不少其人写的文章。
从心底同意了师父之前说的一句话，别人写的文章，就像是别人吃过的饭，尽量少吃，要自己多看源码。形形色色的描述冲突，甚至错误（在目前看来是错误的），因为我自己也看不懂git的官方文档，翻译了一大堆，也没找准地方，费时费力，还没方向，就及时放弃了。
怎么说呢，类似于这种东西，可以自己尝试一下，试一下就什么都知道了，在本地（windows）中可以随便写个txt文件，加上换行，然后16进制打开，然后提交到远程，然后根据不同的配置，将不同的远程文件也根据16进制打开，对比一下结果就什么都一目了然了。时间比较紧，这个事情等有空了可以尝试一下。
怎么描述呢，感觉一言难尽，付付还是谁说过，面向百度编程，我很赞同，但是百度上的东西良莠不齐，鱼龙混杂，没有详细的琢磨过，真的无法体会，到了自己身上了，经历过了，解决了，才会成为自己的一部分，而不是看着网上的教程，踩着别人的就脚印一步步过去，就算是自己吧问题解决了，当然，这也叫解决问题，但是不叫经历，不叫成长。