原因:

在各作業系統下，文字檔案所使用的換行符是不一樣的。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是0x0D（CR），後來的 OS X 在更換核心後與 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作為換行符。

這種不統一確實對跨平臺的檔案交換帶來麻煩。雖然靠譜的文字編輯器和 IDE 都支援這幾種換行符，但檔案在儲存時總要有一個固定的標準啊，比如跨平臺協作的專案原始碼，到底儲存為哪種風格的換行符呢？

Git 作為一個原始碼版本控制系統，對這個問題提供了一個“解決方案”。Git 由大名鼎鼎的 Linus 開發，最初只可運行於 *nix 系統，因此推薦只將 UNIX 風格的換行符儲存入庫。但它也考慮到跨平臺協作的場景，並且提供了一個“換行符自動轉換”功能。

這個功能預設處於“自動模式”，當你在簽出檔案時，它試圖將 UNIX 換行符（LF）替換為 Windows 的換行符（CRLF）；當你在提交檔案時，它又試圖將 CRLF 替換為 LF。

Git：

Git 的“換行符自動轉換”功能聽起來似乎很智慧、很貼心，因為它試圖一方面保持倉庫內檔案的一致性（UNIX 風格），一方面又保證本地檔案的相容性（Windows 風格）。但遺憾的是，這個功能是有 bug 的，而且在短期內都不太可能會修正。

問題具體表現在，如果你手頭的這個檔案是一個包含中文字元的 UTF-8 檔案，那麼這個“換行符自動轉換”功能 在提交時是不工作的（但簽出時的轉換處理沒有問題）。我猜測可能這個功能模組在處理中文字元 + CRLF 這對組合時直接崩潰返回了。

示例：

你在 Windows 下用預設狀態的 Git 簽出一個檔案，寫了一行中文註釋（或者這個檔案本來就包含中文），然後存檔提交……不經意間，你的檔案就被毀掉了。

問題分析：

因為你提交到倉庫的檔案已經完全變成了 Windows 風格（簽出時把 UNIX 風格轉成了 Windows 風格但提交時並沒有轉換），每一行都有修改（參見本文開頭的示意圖），而這個修改又不可見（大多數 diff 工具很難清楚地顯示出換行符），這最終導致誰也看不出你這次提交到底修改了什麼。