《Git學習指南》——1.2 版本庫，分布式工作的基礎所在

本節書摘來自異步社群《git學習指南》一書中的第1章，第1.2節，作者： 【德】rené preißel（普萊貝爾） , bjørn stachmann（斯拉赫曼）著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

其實，版本庫本質上就是一個高效的資料存儲結構而已，由以下部分組成。

檔案（即blob）：這裡既包含了文本也包含了二進制資料，這些資料将不以檔案名的形式被儲存。

目錄（即tree）：目錄中儲存的是與檔案名相關聯的内容，其中也會包含其他目錄。

版本（即commit）：每一個版本所定義的都是相應目錄的某個可恢複的狀态。每當我們建立一個新的版本時，其作者、時間、注釋以及其之前的版本都将會被儲存下來。

對于所有的資料，它們都會被計算成一個十六進制散列值（例如像1632acb65b01 c6b621d6e1105205773931bb1a41這樣的值）。這個散列值将會被用作相關對象的引用，以及日後恢複資料時所需的鍵值（見圖1.3）。

圖1.3　版本庫中的對象存儲

也就是說，一個送出對象的散列值實際上就是它的“版本号”，如果我們持有某一送出的散列值，就可以用它來檢查對應版本是否存在于某一版本庫中。如果存在，我們就可以将其恢複到目前工作區相應的目錄中。如果該版本不存在，我們也可以從其他版本庫中單獨導入（拉回）該送出所引用的全部對象。

接下來，我們來看看采用這種散列值和這種既定的版本庫結構究竟有哪些優勢。

高性能：通過散列值來通路資料是非常快的。

備援度——釋放存儲空間：相同的檔案内容隻需存儲一次即可。

分布式版本号：由于相關散列值是根據檔案，作者和日期來計算的，是以版本也可以“離線”産生，不用擔心将來會是以而發生版本沖突。

版本庫間的高效同步：當我們将某一送出從一個版本庫傳遞給另一個版本庫時，隻需要傳送那些目标版本庫中不存在的對象即可。而正是因為有了散列值的幫助，我們才能很快地判斷相關對象是否已經存在。

資料完整性：由于散列值是根據資料的内容來計算的，是以我們可以随時通過git來檢視某一散列值是否與相關資料比對。以檢測該資料上可能的意外變化或惡意操作。

自動重命名檢測：被重命名的檔案可以被自動檢測到，因為根據該檔案内容計算出的散列值并沒有發生變化。也正因為如此，git中并沒有專用的重命名指令，隻需移動指令即可。