第 9 章 附錄 A: Git的缺點

有一些Git的問題，我已經(jīng)藏在毯子下面了。有些可以通過腳本或回調(diào)方法輕易地解決， 有些需要重組或重定義項目，少數(shù)剩下的煩惱，還只能等待?；蛘吒玫兀度脒M來幫 忙。

SHA1 的弱點

隨著時間的推移，密碼學(xué)家發(fā)現(xiàn)越來越多的SHA1的弱點。已經(jīng)發(fā)現(xiàn)對對資源雄厚的組織 哈希沖撞是可能的。在幾年內(nèi)，或許甚至一個一般的PC也將有足夠計算能力悄悄摧毀一 個Git倉庫。

希望在進一步研究摧毀SHA1之前，Git能遷移到一個更好的哈希算法。

微軟 Windows

Git在微軟Windows上可能有些繁瑣：

• Cygwin?，, 一個Windows下的類Linux的環(huán)境，包含一個?一個Git在Windows下的移植.
• 基于MSys的Git?是另一個，要求最小運行時支持，不過一些命令不能馬上工作。

不相關(guān)的文件

如果你的項目非常大，包含很多不相關(guān)的文件，而且正在不斷改變，Git可能比其他系統(tǒng) 更不管用，因為獨立的文件是不被跟蹤的。Git跟蹤整個項目的變更，這通常才是有益的。

一個方案是將你的項目拆成小塊，每個都由相關(guān)文件組成。如果你仍然希望在同一個資 源庫里保存所有內(nèi)容的話，可以使用?git submodule?。

誰在編輯什么？

一些版本控制系統(tǒng)在編輯前強迫你顯示地用某個方法標記一個文件。盡管這種要求很煩 人，尤其是需要和中心服務(wù)器通訊時，不過它還是有以下兩個好處的：

1. 比較速度快，因為只有被標記的文件需要檢查。
2. 可以知道誰在這個文件上工作，通過查詢在中心服務(wù)器誰把這個文件標記為編輯狀 態(tài)。

使用適當?shù)哪_本，你也可以使Git達到同樣的效果。這要求程序員協(xié)同工作，當他編輯一 個文件的時候還要運行特定的腳本。

文件歷史

因為Git記錄的是項目范圍的變更，重造單一文件的變更歷史比其他跟蹤單一文件的版本 控制系統(tǒng)要稍微麻煩些。

好在麻煩還不大，也是值得的，因為Git其他的操作難以置信地高效。例如，git checkout比cp -a都快，而且項目范圍的delta壓縮也比基于文件的delta集合的做法 好多了。

初始克隆

The initial cost is worth paying in the long run, as most future operations will then be fast and offline. However, in some situations, it may be preferable to create a shallow clone with the?--depth?option. This is much faster, but the resulting clone has reduced functionality.

當一個項目歷史很長后，與在其他版本系統(tǒng)里的檢出代碼相比，創(chuàng)建一個克隆的開銷會 大的多。

長遠來看，開始付出的代價還是值得付出的，因為大多將來的操作將由此變得很快，并 可以離線完成。然而，在一些情況下，使用--depth創(chuàng)建一個淺克隆比較劃算些。這種 克隆初始化的更快，但得到克隆的功能有所削減。

不穩(wěn)定的項目

變更的大小決定寫入的速度快慢是Git的設(shè)計。一般人做了小的改動就會提交新版本。這 里一行臭蟲修改，那里一個新功能，修改掉的注釋等等。但如果你的文件在相鄰版本之 間存在極大的差異，那每次提交時，你的歷史記錄會以整個項目的大小增長。

任何版本控制系統(tǒng)對此都束手無策，但標準的Git用戶將遭受更多，因為一般來說，歷史 記錄也會被克隆。

應(yīng)該檢查一下變更巨大的原因。或許文件格式需要改變一下。小修改應(yīng)該僅僅導(dǎo)致幾個 文件的細小改動。

或許，數(shù)據(jù)庫或備份/打包方案才是正選，而不是版本控制系統(tǒng)。例如，版本控制就不適 宜用來管理網(wǎng)絡(luò)攝像頭周期性拍下的照片。

如果這些文件實在需要不斷更改，他們實在需要版本控制，一個可能的辦法是以中心的 方式使用Git?？梢詣?chuàng)建淺克隆，這樣檢出的較少，也沒有項目的歷史記錄。當然，很多 Git工具就不能用了，并且修復(fù)必須以補丁的形式提交。這也許還不錯，因為似乎沒人需 要大幅度變化的不穩(wěn)定文件歷史。

另一個例子是基于固件的項目，使用巨大的二進制文件形式。用戶對固件文件的變化歷 史沒有興趣，更新的壓縮比很低，因此固件修訂將使倉庫無謂的變大。

這種情況，源碼應(yīng)該保存在一個Git倉庫里，二進制文件應(yīng)該單獨保存。為了簡化問題， 應(yīng)該發(fā)布一個腳本，使用Git克隆源碼，對固件只做同步或Git淺克隆。

全局計數(shù)器

一些中心版本控制系統(tǒng)維護一個正整數(shù)，當一個新提交被接受的時候這個整數(shù)就增長。Git則是通過哈希值來記錄所有變更，這在大多數(shù)情況下都工作的不錯。

但一些人喜歡使用整數(shù)的方法。幸運的是，很容易就可以寫個腳本，這樣每次更新，中心Git倉庫就增大這個整數(shù)，或使用tag的方式，把最新提交的哈希值與這個整數(shù)關(guān)聯(lián)起來。

每個克隆都可以維護這么個計數(shù)器，但這或許沒什么用，因為只有中心倉庫以及它的計數(shù)器對每個人才有意義。

空子目錄

空子目錄不可加入管理。可以通過創(chuàng)建一個空文件以繞過這個問題。

Git的當前實現(xiàn)，而不是它的設(shè)計，是造成這個缺陷的原因。如果運氣好，一旦Git得到 更多關(guān)注，更多用戶要求這個功能，這個功能就會被實現(xiàn)。

初始提交

傳統(tǒng)的計算機系統(tǒng)從0計數(shù)，而不是1。不幸的是，關(guān)于提交，Git并不遵從這一約定。很 多命令在初始提交之前都不友好。另外，一些極少數(shù)的情況必須作特別地處理。例如重 訂一個使用不同初始提交的分支。

Git將從定義零提交中受益：一旦一個倉庫被創(chuàng)建起來，HEAD將被設(shè)為包含20個零字節(jié) 的字符串。這個特別的提交代表一棵空的樹，沒有父節(jié)點，早于所有Git倉庫。

然后運行g(shù)it log，比如，通知用戶至今還沒有提交過變更，而不是報告致命錯誤并退出。 這與其他工具類似。

每個初始提交都隱式地成為這個零提交的后代。

不幸的是還有更糟糕的情況。如果把幾個具有不同初始提交的分支合并到一起，之后的 重新修訂不可避免的需要人員的介入。

接口怪癖

對提交A和提交B，表達式“A..B”和“A…B”的含義，取決于命令期望兩個終點還是一 個范圍。參見?git help diff?和?git help rev-parse?。