如何解決git多系統協作時換行符問題

小編給大家分享一下如何解決git多系統協作時換行符問題，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

格式化與空白

格式化與空白是許多開發人員在協作時，特別是在跨平臺情況下，遇到的令人頭疼的細小問題。由于編輯器的不同或者Windows程序員在跨平臺項目中的文件行尾加入了回車換行符，一些細微的空格變化會不經意地進入大家合作的工作或提交的補丁中。不用怕，Git 的一些配置選項會幫助你解決這些問題。

core.autocrlf

假如你正在Windows上寫程序，又或者你正在和其他人合作，他們在Windows上編程，而你卻在其他系統上，在這些情況下，你可能會遇到行尾結束符問題。這是因為Windows使用回車和換行兩個字符來結束一行，而Mac和Linux只使用換行一個字符。雖然這是小問題，但它會極大地擾亂跨平臺協作。

Git可以在你提交時自動地把行結束符CRLF轉換成LF，而在簽出代碼時把LF轉換成CRLF。用core.autocrlf來打開此項功能，如果是在Windows系統上，把它設置成true，這樣當簽出代碼時，LF會被轉換成CRLF：

$ git config --global core.autocrlf true

Linux或Mac系統使用LF作為行結束符，因此你不想 Git 在簽出文件時進行自動的轉換；當一個以CRLF為行結束符的文件不小心被引入時你肯定想進行修正，把core.autocrlf設置成input來告訴 Git 在提交時把CRLF轉換成LF，簽出時不轉換：

$ git config --global core.autocrlf input

這樣會在Windows系統上的簽出文件中保留CRLF，會在Mac和Linux系統上，包括倉庫中保留LF。

如果你是Windows程序員，且正在開發僅運行在Windows上的項目，可以設置false取消此功能，把回車符記錄在庫中：

$ git config --global core.autocrlf false

core.whitespace

Git預先設置了一些選項來探測和修正空白問題，其4種主要選項中的2個默認被打開，另2個被關閉，你可以自由地打開或關閉它們。

默認被打開的2個選項是trailing-space和space-before-tab，trailing-space會查找每行結尾的空格，space-before-tab會查找每行開頭的制表符前的空格。

默認被關閉的2個選項是indent-with-non-tab和cr-at-eol，indent-with-non-tab會查找8個以上空格（非制表符）開頭的行，cr-at-eol讓 Git 知道行尾回車符是合法的。

設置core.whitespace，按照你的意圖來打開或關閉選項，選項以逗號分割。通過逗號分割的鏈中去掉選項或在選項前加-來關閉，例如，如果你想要打開除了cr-at-eol之外的所有選項：

$ git config --global core.whitespace \
    trailing-space,space-before-tab,indent-with-non-tab

當你運行git diff命令且為輸出著色時，Git 探測到這些問題，因此你也許在提交前能修復它們，當你用git apply打補丁時同樣也會從中受益。如果正準備運用的補丁有特別的空白問題，你可以讓 Git 發警告：

$ git apply --whitespace=warn <patch>

或者讓 Git 在打上補丁前自動修正此問題：

$ git apply --whitespace=fix <patch>

這些選項也能運用于衍合。如果提交了有空白問題的文件但還沒推送到上流，你可以運行帶有--whitespace=fix選項的rebase來讓Git在重寫補丁時自動修正它們。

服務器端配置

Git服務器端的配置選項并不多，但仍有一些饒有生趣的選項值得你一看。

receive.fsckObjects

Git默認情況下不會在推送期間檢查所有對象的一致性。雖然會確認每個對象的有效性以及是否仍然匹配SHA-1檢驗和，但 Git 不會在每次推送時都檢查一致性。對于 Git 來說，庫或推送的文件越大，這個操作代價就相對越高，每次推送會消耗更多時間，如果想在每次推送時 Git 都檢查一致性，設置receive.fsckObjects 為true來強迫它這么做：

$ git config --system receive.fsckObjects true

現在 Git 會在每次推送生效前檢查庫的完整性，確保有問題的客戶端沒有引入破壞性的數據。

receive.denyNonFastForwards

如果對已經被推送的提交歷史做衍合，繼而再推送，又或者以其它方式推送一個提交歷史至遠程分支，且該提交歷史沒在這個遠程分支中，這樣的推送會被拒絕。這通常是個很好的禁止策略，但有時你在做衍合并確定要更新遠程分支，可以在push命令后加-f標志來強制更新。

要禁用這樣的強制更新功能，可以設置receive.denyNonFastForwards：

$ git config --system receive.denyNonFastForwards true

稍后你會看到，用服務器端的接收鉤子也能達到同樣的目的。這個方法可以做更細致的控制，例如：禁用特定的用戶做強制更新。

receive.denyDeletes

規避denyNonFastForwards策略的方法之一就是用戶刪除分支，然后推回新的引用。在更新的 Git 版本中（從1.6.1版本開始），把receive.denyDeletes設置為true：

$ git config --system receive.denyDeletes true

這樣會在推送過程中阻止刪除分支和標簽 — 沒有用戶能夠這么做。要刪除遠程分支，必須從服務器手動刪除引用文件。通過用戶訪問控制列表也能這么做，

以上是“如何解決git多系統協作時換行符問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！