如果你在一個Windows開發團隊中–更甚者在一個跨平臺的開發團隊中，那么必須要面對的問題之一就是行結束符(line endings)。您的行結束符設置可能會影響開發效率并引發一系列問題。

處理行結束符的關鍵是確保您的. gitattributes配置文件已正常提交到代碼倉庫。對大多數人來說，在倉庫的根目錄創建一個名為 .gitattributes的文件，并添加下述配置是十分簡單的。

* text=auto

設置了如上配置后，當將文件添加到倉庫中時，Windows用戶可以將它們從Windows樣式的行結束符(\r\n)轉換為Unix樣式的行結束符(\n)。

如果你對這些內容已經感到無聊了，那么你可以馬上停止閱讀。對于大多數開發人員來說–在大多數代碼倉庫中–這些知識就已經足夠了。

為什么不使用core.autocrlf?

最初，Git for Windows引入了一種不同的行結束符表示方法:core.autocrlf。這是一種類似于屬性機制的表示方法，其思想是，Windows用戶如果設置了Git配置選項core.autocrlf=true，當他們向倉庫添加文件時，他們的行結束符將被轉換為Unix樣式的行結束符。

這兩個選項之間的區別很微小，但很關鍵： .gitattributes是在代碼倉庫中設置的，所以它可以與其他人共享。但是core.autocrlf是在本地Git配置中設置的。這意味著每個人都必須記住設置它，并且設置成相同的參數值。

首先，配置該選項最好的時機是當你在Windows安裝Git時:

您需要點擊第一個選項，但是如果您是第一次運行安裝程序，您很可能并不知道這一點，這是可以諒解的。

core.autocrlf的問題是，如果有些人將它設置為true，而有些人沒有，那么在您的代碼倉庫中會出現混合的行結束符。這并不好——因為他的設置并不只是告訴Git你希望它如何處理進入你的代碼倉庫的文件。它還告訴Git您已經做了什么，以及已經加入倉庫的文件行結束符是什么樣子。

這就是為什么行結束符配置最常見的問題之一就是是看到“phantom changes”:執行git status命令告訴您已經更改了一個文件，但是運行git diff看不到任何修改。為什么會這樣呢？就是因為行結束符。

Phantom Changes

假設某個文件以Windows風格的行結束符加入到您的代碼倉庫中。由于某種原因，有人在添加文件時沒有設置core.autocrlf=true。另一方面，你作為一個熟練的Windows git用戶，設置了這個選項。

當您運行git status時，git將查看該文件以判斷您是否對其進行了任何更改。當它將你磁盤上的內容與代碼倉庫中的內容進行比較時，它會將你本地倉庫中磁盤上的行結束符從Windows風格轉換為Unix風格。由于代碼倉庫中現有的文件都使用Windows風格的行結束符，而您希望它們是Unix風格的(按照你本地的配置)，git將判斷該文件是不同的。(從字節維度對比，確實不一樣。)

通過使用.gitattributes，您可以確保這些設置存在于倉庫級別，而不是讓每個用戶來進行正確配置。這意味著就不用擔心個人用戶可能會配置錯誤。

當然，設置它的最佳時間是在您創建代碼倉庫之時，在您添加任何文件之前。事后進行設置意味著您可能仍然有一些文件使用了錯誤的配置項。

隨著時間的推移，這些文件會隨著您的編輯而更新。您可以嘗試重新規范化文件，更新行結束符，但是這樣做會導致在重新規范文件之前就已經創建的分支在合并時會出現令人討厭的沖突。

對于二進制文件呢 ?

一般來說，git非常擅長檢測一個文件是否是二進制文件。如果它判斷一個文件是二進制文件，那么它將拒絕轉換行結束符。但是我們仍然推薦顯式配置git不轉換二進制文件的行結束符。

如果您不想某些文件進行行結束符的轉化，您可以刪除這些文件的文本屬性。例如，如果您的倉庫中中有png，那么對應的.gitattributes配置文件可能如下所示:

* text=auto *.png -text

當然， .gitattributes 的應用還有很多方面。在某些特定的開發場景中會特別有用。我們將在下一篇博文中深入探討其中的一些——比如使用Unity。

原文鏈接:
https://www.edwardthomson.com/blog/git_for_windows_line_endings.html

總結

以上是生活随笔為你收集整理的Windows下关于Git的行结束符的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。