引言

在做嵌入式 Linux 开发的的程序员，不乏在 Windows 环境下编写代码，然后再复制到 Linux 系统中进行编译。代码托管或者版本管理绝大部分使用 git。

这样的开发流程，相信很多开发者在用：从 git 拉取代码到 Windows 系统中，添加或修改代码后，复制到 Linux 中进行编译，然后再下载到目标板运行。

然而，本来应该是正常的开发，却遇到了问题。

问题描述

某个项目需要添加新的功能，便从 git 服务器上拉取已有的工程代码到 Windows 系统进行开发。修改完代码之后，复制到 Linux 虚拟机进行编译，却发现报错了，编译不通过。

当时觉得很奇怪，已经上线的程序，竟然会编译失败。经过一些列的对比查找，发现了一些端倪，代码文件真的不一样！

在 Linux 系统中打开工程文件，发现每行的结尾有特殊符号 “^M”。由此考虑，应该是文件换行符不一致引起的错误。这个特殊的换行符，使得工程中有些关键脚本文件执行失败，从而导致工程编译失败或者目标程序执行异常。

为什么会出现特殊符号 “^M” 呢？

问题原因

不同操作系统的换行符是不一样的。Unix/Linux 系统使用的是 LF 用作换行符；Windows 一直使用的 CRLF（即，回车 CR和换行 LF）作为换行符。将 Windows 系统下的文件，在Linux 下打开，就会在每行的末尾显示 “^M”。

然而， git 入库的代码采用的是 LF 格式换行。

为了实现跨平台的写作，git 提供了 “换行符自动转换” 功能。如果在 Windows 安装 git，在拉取文件时，会自动将 LF 换行符替换为 CRLF：在提交时，又会将 CRLF 转化为 LF。

问题解决

解决问题的方法是：禁用 git 的换行符自动转换功能。

解决方法一

修改 git 的本地配置文件。在本地路径 C:\Users\[用户名]目录下，找到配置文件 .gitconfig，在 “[core]” 下添加如下内容：

autocrlf = false
filemode = false
safecrl = true

解决方法二

通过命令行修改 git 的配置：

/* 不转换换行符 */
git config --global core.autocrlf false

/* 忽略文件权限修改 */
git config --global core.filemode false

/* 允许提交包含混合换行符的文件 */
git config --global core.safecrlf true