1 autocrlf与safecrlf
git config --global core.autocrlf true #提交时转换为LF，检出时转换为CRLF git config --global core.autocrlf input #提交时转换为LF，检出时不转换 git config --global core.autocrlf false #提交检出均不转换 git config --global core.safecrlf true #拒绝提交包含混合换行符的文件
text 告诉git该文件是text，怎么处理要看eol设置(for 单独文件类型)，或者core.eol设置(for 所有文件)，以及其他设置选项。
text=auto 告诉git自动的进程换行符转换，git会自动判断文件是否是text文件类型。
[text] eol=crlf 告诉git对该类型文件进行换行符转换，转成crlf。
[text] eol=lf 告诉git对该类型文件进程换行符转换，转成lf。
binary 告诉git对该类型文件不要进行换行符转换。
2 git config -l
查看开发机器是否配置了 core.autocrlf：git config -l，我的机器是Windows系统，默认是 core.autocrlf=true，如下图：
使用 autocrlf=true，下载 git上的zip文件查看后，发现换行符都是 LF，但在Windos下使用 git clone 下来的代码却是CRLF，这这正是 autocrlf=true 的作用。
3 gitattributes文件示例
# 对任何文件，设置text=auto，表示文件的行尾自动转换。如果是文本文件，则在文件入Git库时，行尾自动转换为LF。如果已经在入Git库中的文件的行尾为CRLF，则该文件在入Git库时，不再转换为LF。 * text=auto # 对于txt文件，标记为文本文件，并进行行尾规范化（按text=auto来）。 *.txt text # 对于jpg文件，标记为非文本文件，不进行任何的行尾转换。 *.jpg -text # 对于vcproj文件，标记为文本文件，在文件入Git库时进行规范化，即行尾为LF。但是在检出到工作目录时，行尾自动转换为CRLF。 *.vcproj text eol=crlf # 对于sh文件，标记为文本文件，在文件入Git库时进行规范化，即行尾为LF。在检出到工作目录时，行尾也不会转换为CRLF（即保持LF）。 *.sh text eol=lf # 对于py文件，只针对工作目录中的文件，行尾为LF。 *.py eol=lf
4 .gitattributes中的 text=auto
实际上，git本身首先会看git repo里面的 .gitattributes 文件设置,例如下面的设置会自动的对java文件进行换行符转换。
其次才会看 core.autocrlf 设置。所以最好在git code repo里面设置一下：
5 多分支情况下，请保证 .gitattributes 文件一致，否则可能出问题
下面说下工作中遇到的一个坑。
在 dev 分支的 .gitattributes 上，设置“src/test/resources/config/* text eol=lf”后，重新clone这个项目测试，发现只有3个config符合预期格式化为 LF，
其他6个配置还是 CRLF。
尝试了各种办法，包括删除这些配置再重新clone新的项目恢复等都不管用。
最后将 dev 合并到 master 解决问题。
问题重现：
第一步：创建一个新项目，添加 test_crlf.txt，并 push 到 bitbucket。
第二步：从远程master分支克隆一个 dev 分支到本地，并添加 .gitattributes 文件，内容如下：
—————————————————————————-
* text=auto
# all config files should have Linux LF as the eol
src/test/resources/config/* text eol=lf
—————————————————————————-
然后可以将 test_crlf.txt 里的 CRLF 改为 LF，或者不改也无所谓。然后 push 到 bitbucket。
第三步：git clone 项目，发现 dev 分支上的 test_crlf.txt 并没有格式化，还是 CRLF。
经测试，解决办法：
（1）将 dev 合并到 master 解决问题
（2）或者不合并，直接到 master 下添加 “src/test/resources/dptech-fw/general/config/* text eol=lf”