前言
解释一些概念：
CRLF：回车换行。CR：即平常说的\r，回车；LF：即\n，换行。
windows下换行符为CRLF，unix系统（如linux，现在的mac等）用LF。
git服务器，一般是在linux上部署。
git客户端，即我们的开发环境，个人工作环境，集成部署发布环境等，可能是windows、mac、linux等。
本文以git客户端在windows下环境说明，在unix环境就不太可能遇到我说的这个问题了。
以我个人机器的默认git客户端配置来说，在检出和检入时，行尾换行符会做相关转换。如：我在windows下写的代码，提交仓库时，行尾的换行符CRLF会转换为LF（官方术语：normalization，标准化），这个时间点我测试是在提交代码到本地仓库的时候，不是推送远程。当从远程拉取代码到本地的时候，行尾换行符会转换（官方术语：conversion，转换），从LF到CRLF，因为我是windows环境，这个是自动识别转换了。
接下来说个业务场景，抛砖引玉。
业务背景
我在windows下写了个应用启停的shell脚本，提交到git仓库。测试人员会拉取代码，将项目打包部署到测试环境然后使用这个脚本启动。
问题：在windows下换行符是CRLF，提交仓库时转换为LF。但测试人员用的也是windows，git默认配置，拉下来转换为CRLF。将这个脚本上传到服务器执行就会出问题，格式不正确，报错类似结束符不正确：\r之类的。
用vim -b打开，看到报错的行尾有个^M之类的符号等。
比较low的方法就是用个转换工具（抱歉，名字突然忘了，建议上网搜一下），将windows格式转换为unix格式，或者vim打开的时候在编辑模式输入：set fileformat=unix回车保存退出即可。
现在，期望的是，不要发生这种转换，测试人员下载下来的时候换行符就是LF，上传到linux执行没有问题。
解决办法
我最开始遇到这类问题，在网上搜过，也了解了下面这个配置：算是自动转换的开关配置。其实对这个场景用处不大，因为，我只需要对其中的几个文件进行处理，并且这个配置只作用于我的客户端，不能让所有协同开发人员都要关心这个配置问题。
git config --global core.autocrlf [true | input | false] 一个很理想的解决办法：
在工程的目录下，建立一个文件，文件名：.gitattributes，和.gitignore很像。
内容如下：检入进行标准化转换为LF，但检出不转换。
*.sh eol=lf.gitattributes，是定义每个路径的属性配置文件，有很多属性，说明：http://schacon.github.io/git/gitattributes.html
上面链接文档，说的很清楚，没必要重复对这个配置进行更多解释，内容也不少，有需要查一下。
说下这个问题：
关于行尾结束符这里，有两个属性参数可以选择设置，每个属性也有几个不同的值。上面的配置：*.sh eol=lf，就是指当前目录下所有sh结尾的文件，设置属性eol，它的值是lf：检入时标准化为LF，检出时阻止转换为CRLF.
eol
This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any content checks, effectively setting the text attribute.
Set to string value "crlf"
This setting forces git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out.
Set to string value "lf"
This setting forces git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out.
这样就解决问题了。
其它属性说明或示例等看上面的链接自查即可。
最后，说下.gitattributes文件位置，不一定必须在工程根目录下，另外该设置项也有优先级（如，全局范围、系统范围、该配置文件距离作用文件的路径距离等都有影响）。
本文仅是作为一个场景示例说明和解决办法。如遇类似问题，可参考相关属性设置或配置项灵活解决。