引言

在做嵌入式 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