Git 处理行结束符
core.autocrlf
1.如果为true，当从读文本文件时，git将行尾的CRLF转换为LF，写文件时进行相反的转换。
2.也可以设置为input，这种情况，只在读取文本文件是进行转换，在写文件时，将LF作为行尾结束符。
3.一个文件是否本认为是文本文件（也就是受到autocrlf机制的约束），依赖文件的crlf属性，或者，如果没有指定crlf属性，那么主要依赖文件的内容。
core.autocrlf 转换
如果core.autocrlf为false，不进行转换。(git config core.autocrlf false)如果core.autocrlf为true，在工作路径中的文件用CRLF作为结束符，当提交(checkin)到代码库时，再转换为LF作为行结束符。如果core.autocrlf被设置为input，在checkin时，行结束符被转换为LF，但是checkout时，则不会转换。
core.safecrlf
If core.safecrlf is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of core.autocrlf. For "true", git rejects irreversible conversions; for "warn", git only prints a warning but accepts an irreversible conversion. The safety triggers to prevent such a conversion done to the files in the work tree, but there are a few exceptions. Even though…git add itself does not touch the files in the work tree, the next checkout would, so the safety triggers;
git apply to update a text file with a patch does touch the files in the work tree, but the operation is about text files and CRLF conversion is about fixing the line ending inconsistencies, so the safety does not trigger;
git diff itself does not touch the files in the work tree, it is often run to inspect the changes you intend to next git add. To catch potential problems early, safety triggers.
在使用git的过程中，如果我们的项目是跨平台开发的
那么CRLF的处理也许会成为一个很头疼的事情，有可能会出以下的莫名其妙的问题：
我们的某个开发人员在linux上提交的一个文件
当从windows上pull下来后，没做任何的修改，查看其status，它的状态已经是modifed了
即使你使用git checkout -f来恢复改文件，它的状态仍然是modified，真是郁闷...
后来，才发现就是CRLF惹的祸
我们都知道，在Windows上是CRLF来作为一行的结束符，而Linux上则是LF作为行结束符
在git中提供了autocrlf的设置，可以用来自动转换CRLF，它可以设置成true,false,input
Windows上的msysgit默认设置了autocrlf为true
这样，在提交时自动地把行结束符CRLF转换成LF，而在签出代码时把LF转换成CRLF
这样保证了从windows平台上提交的代码，都是以LF作为行结束符
在linux平台上，git默认设置autocrlf为false，也即它不会自动处理CRLF
这样就有一个问题，如果我们把windows上的一个文件给上传到linux上，并提交
那么，提交到仓库中的代码就会以CRLF来换行了，
这样就会导致我们在windows上查看改文件的状态就会是modified
解决这个问题有以下2个办法：
在Linux上设置autocrlf为input，这样，Git在提交时把CRLF转换成LF，签出时不转换
对于从Windows上直接拷到Linux上的文件，首先把它转换成linux格式后，再进行提交