行結(jié)束轉(zhuǎn)換是如何與git核心一起工作的。我讀過很多關(guān)于堆棧溢出的不同問題和答案吉特關(guān)于核心設(shè)置有效。從我所讀到的，這就是我的理解：Unix和MacOSX(前置OSX使用CR)客戶端使用LF行尾。Windows客戶端使用CRLF行尾。當(dāng)core.autocrlf在客戶端上設(shè)置為true時，git存儲庫總是以LF行結(jié)束格式存儲文件，客戶端上的文件中的行尾在簽出/提交時來回轉(zhuǎn)換，這些客戶端使用非LF行結(jié)束，無論客戶端上的行尾文件采用何種格式(這與Tim Clem的定義不一致-請參見下面的更新)。下面是一個矩陣，它試圖為core.autocrlf的“輸入”和“false”設(shè)置記錄相同的內(nèi)容，其中我不確定行結(jié)束轉(zhuǎn)換行為。我的問題是：問號應(yīng)該是什么？這個矩陣對“非問號”是正確的嗎？我將更新答案中的問號，因為似乎已經(jīng)形成了共識。                       core.autocrlf value             true            input              false ---------------------------------------------------------- commit   |  convert           ?                  ? new      |  to LF      (convert to LF?)   (no conversion?) commit   |  convert to        ?                 no  existing |  LF         (convert to LF?)     conversion checkout |  convert to        ?                 no existing |  CRLF       (no conversion?)     conversion我并不是真的在尋找各種設(shè)置的正反兩方面的意見。我只是在尋找數(shù)據(jù)，它清楚地說明了如何期望git對這三個設(shè)置中的每一個進(jìn)行操作。--閱讀后蒂姆·克萊姆的文章在注釋中由JJD鏈接，我修改了上表中“未知”值中的一些值，并更改了“簽出現(xiàn)有的true以轉(zhuǎn)換為CRLF，而不是轉(zhuǎn)換為Client”。以下是他給出的定義，這些定義比我在其他地方看到的任何東西都更清晰：core.autocrlf=false這是默認(rèn)情況，但大多數(shù)人都被鼓勵立即改變這種情況。使用false的結(jié)果是，Git永遠(yuǎn)不會處理文件中的行尾。你可以簽入的文件與LF或CRLF或CR或隨機(jī)混合的這三個和Git不在乎。這可能會使差異更難閱讀和合并更加困難。大多數(shù)在Unix/Linux環(huán)境中工作的人使用這個值是因為他們沒有CRLF問題，而且每當(dāng)文件被寫入對象數(shù)據(jù)庫或?qū)懭牍ぷ髂夸洉r，他們不需要Git做額外的工作。core.autocrlf=true這意味著Git將處理所有文本文件，并確保在將該文件寫入對象數(shù)據(jù)庫時用LF替換，并在寫入工作目錄時將所有LF轉(zhuǎn)換回CRLF。這是在Windows上推薦的設(shè)置，因為它確保您的存儲庫可以在其他平臺上使用，同時將CRLF保留在您的工作目錄中。core.autocrlf=輸入這意味著Git將處理所有文本文件，并確保在將該文件寫入對象數(shù)據(jù)庫時用LF替換CRLF。然而，它不會適得其反。當(dāng)您從對象數(shù)據(jù)庫中讀取文件并將它們寫入工作目錄時，它們?nèi)匀挥蠰FS來表示行尾。此設(shè)置通常用于Unix/Linux/OSX，以防止CRLFs被寫入存儲庫。這樣做的想法是，如果您從Web瀏覽器粘貼代碼，并意外地將CRLF放入您的文件中，則Git將確保在寫入對象數(shù)據(jù)庫時將它們替換為LFS。Tim的文章很棒，我唯一能想到的就是他認(rèn)為存儲庫是LF格式的，這不一定是正確的，特別是對于只適用于Windows的項目。將Tim的文章與JmLane迄今投票最多的答案進(jìn)行比較，顯示出對真實和輸入設(shè)置的完美一致，以及對錯誤設(shè)置的不同意見。