這篇筆記記錄 Git 自動處理換行字元所衍生的問題，順便補充先前寫的筆記。
先前寫過一篇筆記：Git 的 core.autocrlf 參數。後來有一段時間都在用 TFS 和 Subversion，直到註冊了 TFS 免費雲端服務，又開始使用 Git。
可是我壓根兒忘了要去設定換行字元這件事。
於是，最近開始出現一個狀況：在不同的電腦上拉回新版本之後，在沒有改動任何檔案的情況下，執行 commit 命令，竟然會出現有些檔案異動過了，讓我提交至伺服器。更慘的是，有些用戶端機器的設定錯誤，以至於連二進位檔案（例如 .DLL）裡面的換行字元都被 Git 強制替換掉，導致 Visual Studio 專案出現編譯錯誤。
於是，這才又去複習了先前的筆記，以及網路上的一些文章。看看自己先前調查的結果是否還適用。其中當然也看了保哥寫的文章：Git 在 Windows 平台處理斷行字元 (CRLF) 的注意事項。在那篇文章裡面，保哥充分展現了研究精神，詳細說明了為什麼我們在使用 Git 時需要關心換行字元的議題。
既然已經有很好的參考資料，那麼在這篇筆記裡面，我就簡單記錄一下自己碰到的問題和應對方法。
先說結論：我不讓 Git 自動轉換任何換行字元，無論是純文字還是二進位檔案。
換行字元會咬人！
某次執行完 git pull 命令更新整個專案之後，Visual Studio 編譯時報錯一堆：Resolved file has a bad image, no metadata, or is otherwise inaccessible。如下圖：
既然是參考的組件有問題，直覺想到先試試用 nuget 把那些出問題的套件再裝一次。結果光是開啟 nuget 套件管理員都會出錯：
即使把 nuget 的 config 檔案裡面逐一刪掉一些套件參考，終於可以開啟套件管理員了。隨後再安裝某些套件時仍會出錯：
這是因為此專案有許多二進位檔案在經過 git 換行字元轉換之後被破壞了。下圖是我將出問題的專案之 nuget 套件目錄下的 System.Web.Mvc.dll 跟另一個專案的 dll 檔案比較的結果，可以看出 0x0D 和 0x0A 被轉成了 0x0A。
Git 沒有錯。錯在我沒注意到某台開發機器的 Git 設定不一樣——它被設定成預設將所有檔案的換行字元一律轉成 0x0A。
光是修正所有的二進位檔（包括圖片也都被破壞了）就費了好一番手腳，才確認所有的檔案皆已復原成正確格式。所以換行字元轉換的問題還是得注意一下，以免浪費寶貴的時間。
文字類型的檔雖然不至於像二進位檔案那樣可能引發嚴重問題，但如果 Git 認為你要它幫你自動處理換行字元的轉換，每次 commit 時就可能多出一些自己根本沒改過的檔案，這也挺煩的。下圖是用 kdiff3 工具比對兩個版本的差異，左邊的換行字元是 DOS 風格（亦即 CRLF），右邊則是 Unix 風格（亦即 LF），可以看出檔案中的換行字元被改過了。
預設是自動轉換 CRLF
Git 的預設行為是自動幫我們處理換行字元的轉換。為了避免每台機器設定不同而產生互相踩腳的情形，最好是在建立 repo（檔案庫）時就針對那個 repo 編寫適當的組態檔（.gitAttributes）。如此一來，無論檔案庫被複製到哪裡，設定都不會跑掉。
設定方法請參考這裡、這裡、或這裡。
修改檔案庫的 .gitAttributes 檔案時，我只是把原本預設的
* text auto
改成這樣：
* -text
也就是告訴 Git：別動我的換行字元，任何檔案都別去動！原本它是 LF 就 LF，原本是 CRLF 就照存 CRLF。
省略「重新正規化」的動作會怎樣？
改完換行字元轉換的設定之後，應該要對檔案庫執行重新正規化的動作。如果省略此步驟，就得靠自己手動修正各檔案。如果都不理它，將來 commit 時，TortoiseGit 會提示某些檔案的換行字元將被修改，如下圖：
如前面提過的，文字檔還好，但二進位檔案就可能會造成嚴重問題，不可輕忽。
參考資料
先前寫過一篇筆記：Git 的 core.autocrlf 參數。後來有一段時間都在用 TFS 和 Subversion，直到註冊了 TFS 免費雲端服務，又開始使用 Git。
可是我壓根兒忘了要去設定換行字元這件事。
於是，最近開始出現一個狀況：在不同的電腦上拉回新版本之後，在沒有改動任何檔案的情況下，執行 commit 命令，竟然會出現有些檔案異動過了，讓我提交至伺服器。更慘的是，有些用戶端機器的設定錯誤，以至於連二進位檔案（例如 .DLL）裡面的換行字元都被 Git 強制替換掉，導致 Visual Studio 專案出現編譯錯誤。
於是，這才又去複習了先前的筆記，以及網路上的一些文章。看看自己先前調查的結果是否還適用。其中當然也看了保哥寫的文章：Git 在 Windows 平台處理斷行字元 (CRLF) 的注意事項。在那篇文章裡面，保哥充分展現了研究精神，詳細說明了為什麼我們在使用 Git 時需要關心換行字元的議題。
既然已經有很好的參考資料，那麼在這篇筆記裡面，我就簡單記錄一下自己碰到的問題和應對方法。
先說結論：我不讓 Git 自動轉換任何換行字元，無論是純文字還是二進位檔案。
換行字元會咬人！
某次執行完 git pull 命令更新整個專案之後，Visual Studio 編譯時報錯一堆：Resolved file has a bad image, no metadata, or is otherwise inaccessible。如下圖：
既然是參考的組件有問題，直覺想到先試試用 nuget 把那些出問題的套件再裝一次。結果光是開啟 nuget 套件管理員都會出錯：
這是因為此專案有許多二進位檔案在經過 git 換行字元轉換之後被破壞了。下圖是我將出問題的專案之 nuget 套件目錄下的 System.Web.Mvc.dll 跟另一個專案的 dll 檔案比較的結果，可以看出 0x0D 和 0x0A 被轉成了 0x0A。
光是修正所有的二進位檔（包括圖片也都被破壞了）就費了好一番手腳，才確認所有的檔案皆已復原成正確格式。所以換行字元轉換的問題還是得注意一下，以免浪費寶貴的時間。
文字類型的檔雖然不至於像二進位檔案那樣可能引發嚴重問題，但如果 Git 認為你要它幫你自動處理換行字元的轉換，每次 commit 時就可能多出一些自己根本沒改過的檔案，這也挺煩的。下圖是用 kdiff3 工具比對兩個版本的差異，左邊的換行字元是 DOS 風格（亦即 CRLF），右邊則是 Unix 風格（亦即 LF），可以看出檔案中的換行字元被改過了。
預設是自動轉換 CRLF
Git 的預設行為是自動幫我們處理換行字元的轉換。為了避免每台機器設定不同而產生互相踩腳的情形，最好是在建立 repo（檔案庫）時就針對那個 repo 編寫適當的組態檔（.gitAttributes）。如此一來，無論檔案庫被複製到哪裡，設定都不會跑掉。
設定方法請參考這裡、這裡、或這裡。
修改檔案庫的 .gitAttributes 檔案時，我只是把原本預設的
* text auto
改成這樣：
* -text
也就是告訴 Git：別動我的換行字元，任何檔案都別去動！原本它是 LF 就 LF，原本是 CRLF 就照存 CRLF。
省略「重新正規化」的動作會怎樣？
改完換行字元轉換的設定之後，應該要對檔案庫執行重新正規化的動作。如果省略此步驟，就得靠自己手動修正各檔案。如果都不理它，將來 commit 時，TortoiseGit 會提示某些檔案的換行字元將被修改，如下圖：
如前面提過的，文字檔還好，但二進位檔案就可能會造成嚴重問題，不可輕忽。
參考資料
沒有留言: