如何解決git多系統(tǒng)協(xié)作時(shí)換行符問題

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

格式化與空白

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

core.autocrlf

假如你正在Windows上寫程序，又或者你正在和其他人合作，他們?cè)赪indows上編程，而你卻在其他系統(tǒng)上，在這些情況下，你可能會(huì)遇到行尾結(jié)束符問題。這是因?yàn)閃indows使用回車和換行兩個(gè)字符來結(jié)束一行，而Mac和Linux只使用換行一個(gè)字符。雖然這是小問題，但它會(huì)極大地?cái)_亂跨平臺(tái)協(xié)作。

Git可以在你提交時(shí)自動(dòng)地把行結(jié)束符CRLF轉(zhuǎn)換成LF，而在簽出代碼時(shí)把LF轉(zhuǎn)換成CRLF。用core.autocrlf來打開此項(xiàng)功能，如果是在Windows系統(tǒng)上，把它設(shè)置成true，這樣當(dāng)簽出代碼時(shí)，LF會(huì)被轉(zhuǎn)換成CRLF：

$ git config --global core.autocrlf true

Linux或Mac系統(tǒng)使用LF作為行結(jié)束符，因此你不想 Git 在簽出文件時(shí)進(jìn)行自動(dòng)的轉(zhuǎn)換；當(dāng)一個(gè)以CRLF為行結(jié)束符的文件不小心被引入時(shí)你肯定想進(jìn)行修正，把core.autocrlf設(shè)置成input來告訴 Git 在提交時(shí)把CRLF轉(zhuǎn)換成LF，簽出時(shí)不轉(zhuǎn)換：

$ git config --global core.autocrlf input

這樣會(huì)在Windows系統(tǒng)上的簽出文件中保留CRLF，會(huì)在Mac和Linux系統(tǒng)上，包括倉庫中保留LF。

如果你是Windows程序員，且正在開發(fā)僅運(yùn)行在Windows上的項(xiàng)目，可以設(shè)置false取消此功能，把回車符記錄在庫中：

$ git config --global core.autocrlf false

core.whitespace

Git預(yù)先設(shè)置了一些選項(xiàng)來探測(cè)和修正空白問題，其4種主要選項(xiàng)中的2個(gè)默認(rèn)被打開，另2個(gè)被關(guān)閉，你可以自由地打開或關(guān)閉它們。

默認(rèn)被打開的2個(gè)選項(xiàng)是trailing-space和space-before-tab，trailing-space會(huì)查找每行結(jié)尾的空格，space-before-tab會(huì)查找每行開頭的制表符前的空格。

默認(rèn)被關(guān)閉的2個(gè)選項(xiàng)是indent-with-non-tab和cr-at-eol，indent-with-non-tab會(huì)查找8個(gè)以上空格（非制表符）開頭的行，cr-at-eol讓 Git 知道行尾回車符是合法的。

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

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

當(dāng)你運(yùn)行git diff命令且為輸出著色時(shí)，Git 探測(cè)到這些問題，因此你也許在提交前能修復(fù)它們，當(dāng)你用git apply打補(bǔ)丁時(shí)同樣也會(huì)從中受益。如果正準(zhǔn)備運(yùn)用的補(bǔ)丁有特別的空白問題，你可以讓 Git 發(fā)警告：

$ git apply --whitespace=warn <patch>

或者讓 Git 在打上補(bǔ)丁前自動(dòng)修正此問題：

$ git apply --whitespace=fix <patch>

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

服務(wù)器端配置

Git服務(wù)器端的配置選項(xiàng)并不多，但仍有一些饒有生趣的選項(xiàng)值得你一看。

receive.fsckObjects

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

$ git config --system receive.fsckObjects true

現(xiàn)在 Git 會(huì)在每次推送生效前檢查庫的完整性，確保有問題的客戶端沒有引入破壞性的數(shù)據(jù)。

receive.denyNonFastForwards

如果對(duì)已經(jīng)被推送的提交歷史做衍合，繼而再推送，又或者以其它方式推送一個(gè)提交歷史至遠(yuǎn)程分支，且該提交歷史沒在這個(gè)遠(yuǎn)程分支中，這樣的推送會(huì)被拒絕。這通常是個(gè)很好的禁止策略，但有時(shí)你在做衍合并確定要更新遠(yuǎn)程分支，可以在push命令后加-f標(biāo)志來強(qiáng)制更新。

要禁用這樣的強(qiáng)制更新功能，可以設(shè)置receive.denyNonFastForwards：

$ git config --system receive.denyNonFastForwards true

稍后你會(huì)看到，用服務(wù)器端的接收鉤子也能達(dá)到同樣的目的。這個(gè)方法可以做更細(xì)致的控制，例如：禁用特定的用戶做強(qiáng)制更新。

receive.denyDeletes

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

$ git config --system receive.denyDeletes true

這樣會(huì)在推送過程中阻止刪除分支和標(biāo)簽 — 沒有用戶能夠這么做。要?jiǎng)h除遠(yuǎn)程分支，必須從服務(wù)器手動(dòng)刪除引用文件。通過用戶訪問控制列表也能這么做，

以上是“如何解決git多系統(tǒng)協(xié)作時(shí)換行符問題”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！