Git merge 時忽略行尾的 CRLF

如果開發團隊遇到有 Windows 的環境時,常常會遇到 CRLF 和 LF 之間的轉換問題,這時候對 git 做一些小小的設定,可以避免遇到這些問題,預防勝於治療。

CRLF 就是 \r\n,LF 就是 \n,在 vim 底下你會在每一行後面多看到一個 ^M,那個就是 \r

這篇寫出一些「預防」和「治療」的方式,是我剛剛解決問題是用到的,稍微整理一下放上來,如果有熟悉的人發現有錯歡迎在下面 comment,我會儘快改正。

預防

Windows 側

設定這個:

git config --global core.autocrlf true

這在 Windows 下會發生這個效果:當你的 checkout 的檔案帶有 LF 結尾時,會自動轉換成 CRLF 的字串讓你編輯,commit 回去是再切回來原本的 LF。

反之亦然,在 Unix 平臺上會自動把 CRLF 換成 LF,commit 完再變回來 CRLF,不過這沒必要吧.....所以 Unix 可以用下面的設定

Unix-based 側

在 Linux 底下,如果你同事用 Windows 且用成上述的設定時,你可以設定下面這行,讓你的 git 可以在每次 checkout 時,自動把所有的 CRLF 都換成 LF,讓 Windows 那邊去轉換就好:

git config --global core.autocrlf input

治療

Unix-based 側

如果你不幸遇到一堆 CRLF 讓你的 merge 出錯,這邊以 master branch 舉例,你可以直接在 project 的 config 下面設定:

git config merge.renormalize true

這樣在 merge 的時候會忽略到 eol 的 CR 來比對,merge 就不會有因爲 CRLF 和 LF 不一致的問題而發生悲劇。

如果你只要做單一次的 merge,而且之後不會遇到這個問題的話,可以直接 merge:(以 origin 的 master 爲例)

git fetch
git merge -s recursive -X ignore-space-at-eol origin/master

所以這就是爲什麼之前有人建議不要直接 pull,而改做 fetch -> merge 的好處之一。

Windows 側

(自我感覺良好,繼續破壞 project 中)T_T

comments powered by Disqus