Azure DevOps Server (TFS）中代碼文件換行問題解決方案（Git)

以前寫過一篇博客「探索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--