这个功能默认处于“自动模式”，当你在签出文件时，它试图将 UNIX 换行符(LF)替换为 Windows 的换行符(CRLF);当你在提交文件时，它又试图将 CRLF 替换为 LF。

　　(看明白了吗?一个版本控制系统会在你不知不觉的情况下修改你的文件。这 TM 简直酷毙了，对吧?)

　　缺陷

　　Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性(UNIX 风格)，一方面又保证本地文件的兼容性(Windows 风格)。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。

　　问题具体表现在，如果你手头的这个文件是一个 包含中文字符的 UTF-8 文件，那么这个“换行符自动转换”功能 在提交时是不工作的(但签出时的转换处理没有问题)。我猜测可能这个功能模块在处理中文字符 + CRLF 这对组合时直接崩溃返回了。

　　这可能还不是的触发场景(毕竟我没有太多精力陪它玩)，但光这一个坑已经足够了。

　　踩坑

　　这是一个相当大的坑，Windows 下的中文开发者几乎都会中招。举个例子，你在 Windows 下用默认状态的 Git 签出一个文件，写了一行中文注释(或者这个文件本来包含中文)，然后存盘提交……不经意间，你的文件被毁掉了。

　　因为你提交到仓库的文件已经完全变成了 Windows 风格(签出时把 UNIX 风格转成了 Windows 风格但提交时并没有转换)，每一行都有修改(参见本文开头的示意图)，而这个修改又不可见(大多数 diff 工具很难清楚地显示出换行符)，这终导致谁也看不出你这次提交到底修改了什么。

　　这还没完。如果其他小伙伴发现了这个问题、又好心地把换行符改了回来，然后你又再次重演上面的悲剧，那么这个文件的编辑历史基本上成为一个谜团了。

　　由于老外几乎不可能踩到这个坑，使得这个 bug 一直隐秘地存在着。但在网上随便搜一下，会发现受害者不止我一个，比如 这位大哥的遭遇 要比我惨痛得多。

　　防范

　　首先，不要着急去整 Git，先整好自己。你的团队需要确立一个统一的换行符标准(推荐使用 UNIX 风格)。然后，团队的成员们需要分头做好准备工作——配置好自己的代码编辑器和 IDE，达到这两项要求：

　　在新建文件时默认使用团队统一的换行符标准

　　在打开文件时保持现有换行符格式不变(即不做自动转换)

　　这样一方面可以大程度保证项目代码的规范一致，另一方面，即使现有代码中遗留了一些不规范的情况，也不会因为反复转换而导致混乱。(当然，作为一个强迫症患者，我还是祝愿所有的项目从一开始步入严谨有序的轨道。)

　　接下来，我们可以开始调教 Git 了。我的建议是， 完全关掉这个自作聪明的“换行符自动转换”功能。关闭之后，Git 不会对你的换行符做任何手脚了，你可以完全自主地、可预期地控制自己的换行符风格。

　　下面主要针对不同的 Git 客户端，分别介绍一下操作方法。

　　Git for Windows

　　这货由 Git 官方出品，在安装时会向你兜售“换行符自动转换”功能，估计大多数人在看完华丽丽的功能介绍之后会毫不犹豫地选择第一项(自动转换)。请千万抵挡住诱惑，选择后一项(不做任何手脚)。