GIT換行符相關(guān)操作是什么

這篇文章將為大家詳細講解有關(guān)GIT換行符相關(guān)操作是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

背景

關(guān)于“回車”（carriage return）和“換行”（line feed）這兩個概念的來歷和區(qū)別。在計算機還沒有出現(xiàn)之前，有一種叫做電傳打字機（Teletype Model 33）的玩意，每秒鐘可以打10個字符。但是它有一個問題，就是打完一行換行的時候，要用去0.2秒，正好可以打兩個字符。要是在這0.2秒里面，又有新的字符傳過來，那么這個字符將丟失。

于是，研制人員想了個辦法解決這個問題，就是在每行后面加兩個表示結(jié)束的字符。一個叫做“回車”，告訴打字機把打印頭定位在左邊界；另一個叫做“換行”，告訴打字機把紙向下移一行。

后來，計算機發(fā)明了，這兩個概念也就被般到了計算機上。那時，存儲器很貴，一些科學(xué)家認為在每行結(jié)尾加兩個字符太浪費了，加一個就可以。于是，就出現(xiàn)了分歧。Unix系統(tǒng)里，每行結(jié)尾只有“<換行>”，即“\n”；Windows系統(tǒng)里面，每行結(jié)尾是“ <回車><換行>”，即“\r\n”；Mac系統(tǒng)里，每行結(jié)尾是“<回車>”。一個直接后果是，Unix/Mac系統(tǒng)下的文件在Windows里打開的話，所有文字會變成一行；而Windows里的文件在Unix/Mac下打開的話，在每行的結(jié)尾可能會多出一個^M符號。

Windows創(chuàng)建的文件是 \n\r結(jié)束的， 而Linux等類Unix操作系統(tǒng)是\n結(jié)束的。所以Unix的文本到Windows會出現(xiàn)換行丟失（ultraedit這類軟件可以正確識別）； 而反過來就會出現(xiàn)^M的符號了

Windows等操作系統(tǒng)用的文本換行符和Unix/Linux操作系統(tǒng)用的不同，Windows系統(tǒng)下輸入的換行符在Unix/Linux下不會顯示為“換行”，而是顯示為 ^M 這個符號（這是Linux等系統(tǒng)下規(guī)定的特殊標記，占一個字符大小，不是 ^ 和 M 的組合，打印不出來的）。Linux下很多文本編輯器（命令行）會在顯示這個標記之后，補上一個自己的換行符，以避免內(nèi)容混亂（只是用于顯示，補充的換行符不會寫入文件，有專門的命令將Windows換行符替換為Linux換行符）。 Unix/Linux系統(tǒng)下的換行符在Windows系統(tǒng)的文本編輯器中會被忽略，整個文本會亂成一團。

Git 換行符自動轉(zhuǎn)換

Git 的“換行符自動轉(zhuǎn)換”功能聽起來似乎很智能、很貼心，因為它試圖一方面保持倉庫內(nèi)文件的一致性（UNIX 風(fēng)格），一方面又保證本地文件的兼容性（Windows 風(fēng)格）。但遺憾的是，這個功能是有 bug 的，而且在短期內(nèi)都不太可能會修正。

問題具體表現(xiàn)在，如果你手頭的這個文件是一個包含中文字符的 UTF-8 文件，那么這個“換行符自動轉(zhuǎn)換”功能 在提交時是不工作的（但簽出時的轉(zhuǎn)換處理沒有問題）。我猜測可能這個功能模塊在處理中文字符 + CRLF 這對組合時直接崩潰返回了。

例子： 你在 Windows 下用默認狀態(tài)的 Git 簽出一個文件，寫了一行中文注釋（或者這個文件本來就包含中文），然后存盤提交……不經(jīng)意間，你的文件就被毀掉了。 因為你提交到倉庫的文件已經(jīng)完全變成了 Windows 風(fēng)格（簽出時把 UNIX 風(fēng)格轉(zhuǎn)成了 Windows 風(fēng)格但提交時并沒有轉(zhuǎn)換），每一行都有修改（參見本文開頭的示意圖），而這個修改又不可見（大多數(shù) diff 工具很難清楚地顯示出換行符），這最終導(dǎo)致誰也看不出你這次提交到底修改了什么。 這還沒完。如果其他小伙伴發(fā)現(xiàn)了這個問題、又好心地把換行符改了回來，然后你又再次重演上面的悲劇，那么這個文件的編輯歷史基本上就成為一個謎團了。 由于老外幾乎不可能踩到這個坑，使得這個 bug 一直隱秘地存在著。

Git 換行符配置建議

多平臺，多 IDE，團隊協(xié)作，跨平臺開發(fā)，這是大多數(shù)項目都會面臨的問題，所以防患于未然，要在項目之初就統(tǒng)一好換行符（項目中技術(shù)管理是一門藝術(shù)啊?。?/p>

團隊需要確定一個統(tǒng)一的換行符標準（推薦使用 UNIX 風(fēng)格，因為 Git 就是使用 UNIX 換行符）

前期準備工作：配置好使用的代碼編輯器與 IDE 達到兩項標準：

1. 在新建文件時默認使用團隊統(tǒng)一的換行符標準

2. 在打開文件時保持現(xiàn)有換行符格式不變（不要做自動轉(zhuǎn)換）

關(guān)閉 Git 換行符自動轉(zhuǎn)換

關(guān)閉之后，Git 就不會對你的換行符做任何手腳了，你可以完全自主地、可預(yù)期地控制自己的換行符風(fēng)格。

下面主要針對不同的 Git 客戶端，分別介紹一下操作方法。

Git for Windows

由 Git 官方出品，在安裝時就會向你兜售“換行符自動轉(zhuǎn)換”功能，估計大多數(shù)人在看完華麗麗的功能介紹之后會毫不猶豫地選擇第一項（自動轉(zhuǎn)換）。請千萬抵擋住誘惑，選擇最后一項（不作任何手腳）。

如果你已經(jīng)做出了錯誤的選擇，也不需要重新安裝，可以直接使用命令行來修改設(shè)置。很簡單，直接打開這貨自帶的命令行工具 Git Bash，輸入以下命令，再敲回車即可： git config --global core.autocrlf false

TortoiseGit

TortoiseGit 作為主力客戶端，實際上是基于 Git for Windows 的一個 GUI 外殼，你在 Git for Windows 所做的設(shè)置會影響 TortoiseGit 的配置。

若未安裝 Git for Windows，可在 Windows 資源管理器窗口中點擊右鍵，選擇“TortoiseGit → Settings → Git”，進行設(shè)置。

GitHub 的 Windows 客戶端

GitHub 的 Windows 客戶端實際上也是一個殼，它自帶了一個便攜版的 Git for Windows。這個便攜版和你自己安裝的 Git for Windows 是相互獨立的，不過它們都會使用同一個配置文件（實際上就是當前用戶主目錄下的 .gitconfig 文件）。

所以如果你已經(jīng)配置好了自己安裝的 Git for Windows，那就不用操心什么了。但如果你的機器上只裝過 GitHub 的 Windows 客戶端，那么最簡單的配置方法就是手工修改配置文件了。

修改 Git 的全局配置文件

進入當前用戶的主目錄，修改 .gitconfig 文件

在 [core] 區(qū)段找到 autocrlf，將它的值改為 false。如果沒找到，就在 [core] 區(qū)段中新增一行： autocrlf = false

事實上上面介紹的所有命令行或圖形界面的配置方法，最終效果都是一樣的，因為本質(zhì)上都是在修改這個配置文件。

關(guān)閉了換行符自動轉(zhuǎn)換，擔(dān)心文件中帶入了 Windows 的回車換行符，Git 為防止這種你的失誤，提供了換行符檢查功能（core.safecrlf），可以在提交時檢查文件是否混用了不同風(fēng)格的換行符。這個功能的選項如下：

• false - 不做任何檢查

• warn - 在提交時檢查并警告

• true - 在提交時檢查，如果發(fā)現(xiàn)混用則拒絕提交

我建議使用最嚴格的 true 選項。

和 core.autocrlf 一樣，你可以通過命令行、圖形界面、配置文件三種方法來修改這個選項。具體操作就不贅述了，大家自己舉一反三吧。

Eclipse 的換行符配置

切換換行符的顯示格式

改為 Unix 風(fēng)格的換行符

Eclipse 自帶 Git 工具關(guān)閉換行符自動轉(zhuǎn)換

關(guān)于GIT換行符相關(guān)操作是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。