引言
在做嵌入式 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
原作者:zppsky16
|