今天小心翼翼地 Fork 了一个项目，本地改好提交，同步到服务器，怀着激动的心情发出 Pull Request……这时发现问题了。我发现 diff 图表显示的更新并不仅是我修改的那几行，而是整个文件都显示为已修改。（下图为示意图）
这看起来很奇怪啊，于是赶紧撤回 Pull Request，自己闷头找原因。
初步定位是文件的换行符问题，因为我发现本地的文件是 Windows 换行符，但很显然大家现在做项目都是用 UNIX 换行符啊。这是一大疑点，于是在反复对比 Web 端和本地的各个文件、各个版本之后，基本定位到了问题所在。
Git 作为一个源码版本控制系统，以一种（我看起来）有点越俎代庖、自作聪明的态度，对这个问题提供了一个“解决方案”。
Git 由大名鼎鼎的 Linus 开发，最初只可运行于 *nix 系统，因此推荐只将 UNIX 风格的换行符保存入库。但它也考虑到跨平台协作的场景，并且提供了一个“换行符自动转换”功能。
这个功能默认处于“自动模式”，当你在签出文件时，它试图将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；当你在提交文件时，它又试图将 CRLF 替换为 LF。
Git缺陷
Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性（UNIX 风格），一方面又保证本地文件的兼容性（Windows 风格）。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。
问题具体表现在，如果你手头的这个文件是一个包含中文字符的 UTF-8 文件，那么这个“换行符自动转换”功能 在提交时是不工作的（但签出时的转换处理没有问题）。我猜测可能这个功能模块在处理中文字符 + CRLF 这对组合时直接崩溃返回了。
防范
首先，不要着急去整 Git，先整好自己。你的团队需要确定一个统一的换行符标准（推荐使用 UNIX 风格）。然后，团队的成员们需要分头做好准备工作——配置好自己的代码编辑器和 IDE，达到这两项要求：
在新建文件时默认使用团队统一的换行符标准
在打开文件时保持现有换行符格式不变（不要做自动转换）
这样一方面可以最大程度保证项目代码的规范一致，另一方面，即使现有代码中遗留了一些不规范的情况，也不会因为反复转换而导致混乱。（当然，作为一个强迫症患者，我还是祝愿所有的项目从一开始就步入严谨有序的轨道。）
接下来，我们就可以开始调教 Git 了。我的建议是， 完全关掉这个自作聪明的“换行符自动转换”功能。关闭之后，Git 就不会对你的换行符做任何手脚了，你可以完全自主地、可预期地控制自己的换行符风格。
在安装界面直接选择第三项，不进行默认转换。
如果·已经·安装那就输入
git config --global core.autocrlf false
还有就是用最顺手的文本编辑器打开 .gitconfig 文件。
在 [core] 区段找到 autocrlf，将它的值改为 false。如果没找到，就在 [core] 区段中新增一行：
autocrlf = false
如果发现变更行数过多，而且增减行数相同，就要警惕是不是出了意外状况。被图形界面惯坏的孩子往往缺乏耐心，对系统信息视而不见，看到按钮就点，容易让小疏忽酿成大事故。所以高手们青睐命令行，并不是没有道理的。
