之前寫過一篇博客“探索TFS Git 庫文件換行（CRLF）的處理方式”，主要是針對TFVC代碼庫的。
下面這篇文章說明如何在TFS的Git庫中處理代碼換行的問題。
概述
在Azure DevOps Server（之前叫TFS） 中使用Git管理源代碼，需要特別注意代碼文件的換行處理。我們在許多團隊碰到這樣現象，開發人員在自己的Windows 中使用Eclipse 或者Visual Studio 編寫和調試代碼，功能都正常。但是，使用TFS 的自動生成和發布功能，將源代碼下載到Linux 或 AIX等非Windows 的服務器上做編譯和其他操作的時候，發現所有的功能都亂套的，甚至連基本的編譯都無法成功。排查原因后發現，導致系統異常的原因是文件換行的格式。
我們在編寫代碼的時候，每次敲擊一次回車鍵，代碼會從下一行開始。實際上，我們在代碼行的最后面插入了一個不可見的字符，這個字符叫做換行符（line ending）。在歷史上，不同的操作系統處理換行符的方式不一樣，例如Windows 使用crlf，Linux 使用lf，而早期的mac使用cr，后來有改為lf了。更加詳細的內容，可以參考我上一篇博客“探索TFS Git 庫文件換行（CRLF）的處理方式”。
在TFS 的Git庫中，服務器和客戶端對於文件換行符也有自己的處理方式。由於不同的開發人員使用不同的工具和操作系統，例如你使用Windows開發調試，而你的同事使用Mac編寫代碼，而TFS代理服務器則使用Linux 編譯打包。如果不能統一處理換行標准，必然會導致許多未知的問題。例如我們在項目實施過程中，經常碰到這樣的問題：“上一次的持續集成成功了，我們沒有修改代碼，怎么這次就出問題了，怎么這次就失敗？”分析原因，TFS服務器在兩次持續集成流程中使用了不同的代理服務器，而不同代理服務器上Git客戶端處理換行的方式不一樣。
解決不同開發人員、不同編譯環境處理Git中的源代碼換行的問題，我們可以使用下面兩個統一的方案：統一開發環境中的Git配置，統一代碼庫的設置。
解決方案
1. 統一開發環境中的Git配置
在開發人員的計算機上配置Git客戶端的全局變量（core.autocrlf），可以強制用戶使用指定的方式處理行尾標識符，例如：
$ git config --global core.autocrlf true
# 按照Windows的方式處理換行符
$ git config --global core.autocrlf input
# 按照Linux的方式處理換行符
2. 統一代碼庫的設置
按照上面的方式處理文件，可以在一台開發計算機上使用統一的標准處理的源代碼。但是，在實際開發過程中，需要按照不同的Git庫做不同的處理。例如，對於存儲.net程序的代碼庫，我們希望使用Windows的方式來處理換行符；對於java和shell腳本，我們希望使用Linux的方式處理換行符。
Git為我們提供了一種機制，可以針對每個庫，設置不同的處理方式。在Git中，有一個特殊的文件.gitattributes。這個文件配置了Git客戶端處理代碼時候的各種設置（https://git-scm.com/docs/gitattributes) 。我們在每個git庫中添加這個文件，再根據自己的需要，修改文件中的設置，就可以實現對不同庫不同處理方式。.gitattributes中的設置會覆蓋用戶在上一章節中的配置。從此以后，無論你的開發人員工作在哪個平台上，只要他下載已經配置.gitattributes文件的代碼庫，就會按照我們指定的方式處理換行符。
.gitattributes必須放置在代碼庫的根目錄下。保存的方式與我們提交、推送的方式完全一樣。你可以把它視為一個普通的代碼文件。
.gitattributes文件中的內容有點類型一個兩行的表格：
- 左邊的內容表示Git庫中的文件名稱或者文件路徑
- 右邊的內容表示對代碼文件換行符的處理方式
下面是一個簡單的示例：
# 使用默認的方式，開發人員客戶端如何，git就如何處理換行符
* text=auto# 明確指定使用原文件中的換行符
*.c text
*.h text# 指定擴展名為sln的文件名稱，使用Windows的換行符
*.sln text eol=crlf# 指定擴展名為png或jpg的為二進制文件，不需要處理做任何修改
*.png binary
*.jpg binary
從上面的配置，你可以看到，在配置.gitattributes文件時，我們可以使用通配符，例如*.c, *.sln, *.png等。還可以使用空格，在一行中同時指定多種文件。下面，來看一下各種處理文件的配置方式：
- text=auto: Git將按照自己的方式處理文件，一般是按照我們在上一節中配置的方式處理換行符。
- text eol=crlf：在代碼克隆、簽出時，Git總是將換行符轉換為crlf，就是我們Windows常用的格式。即使在Linux或者Mac操作系統中，Git也會按照這種方式處理。
- text eol=lf：在代碼克隆、簽出時，Git總是將換行符轉換為lf，就是我們Linux常用的格式。即使在Windows操作系統中，Git也會按照這種方式處理。
- binary：Git會認為這種文件不是純文本文件，它對這些文件不做任何處理。
3. 后續處理
按照上面的方式配置了你環境或者Git庫后，你會發現實際上本地的文件沒有任何變化。原來是Windows換行的，照樣還是Windows。但是，實際上Git已經迫切希望按照你設定的方式來文件了。
可以參考下面的方式更新你的本地文件，同時還不會丟失目前的工作成果：
1）立即保存目前的所有文件
git add . –u
git commit –m “在刷新文件換行符之前，保存所有更改”
2）刪除Git索引，並且強制Git從小掃描工作目錄
rm .git/index
3）重寫Git的索引文件，並應用最新的換行設置
git reset
4）查看Git狀態
git status
5）將所有修改過的文件添加到提交清單中
git add -u
6）添加.gitattributes文件
git add .gitattributes
7）提交和推送文件
git commit –m “統一文件換行符”
git push
微軟DevOps MVP 張洪君 http://www.cnblogs.com/danzhang
--End--