747      阿裏雲  技術社區[雲棲]

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

本節書摘來自異步社區《Git學習指南》一書中的第1章，第1.2節，作者： 【德】René Preißel（普萊貝爾） , Bjørn Stachmann（斯拉赫曼）著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看

1.2　版本庫，分布式工作的基礎所在

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

文件（即blob）：這裏既包含了文本也包含了二進製數據，這些數據將不以文件名的形式被保存。
目錄（即Tree）：目錄中保存的是與文件名相關聯的內容，其中也會包含其他目錄。
版本（即commit）：每一個版本所定義的都是相應目錄的某個可恢複的狀態。每當我們創建一個新的版本時，其作者、時間、注釋以及其之前的版本都將會被保存下來。
對於所有的數據，它們都會被計算成一個十六進製散列值（例如像1632acb65b01 c6b621d6e1105205773931bb1a41這樣的值）。這個散列值將會被用作相關對象的引用，以及日後恢複數據時所需的鍵值（見圖1.3）。

圖1.3　版本庫中的對象存儲

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

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

高性能：通過散列值來訪問數據是非常快的。
冗餘度——釋放存儲空間：相同的文件內容隻需存儲一次即可。
分布式版本號：由於相關散列值是根據文件，作者和日期來計算的，所以版本也可以“離線”產生，不用擔心將來會因此而發生版本衝突。
版本庫間的高效同步：當我們將某一提交從一個版本庫傳遞給另一個版本庫時，隻需要傳送那些目標版本庫中不存在的對象即可。而正是因為有了散列值的幫助，我們才能很快地判斷相關對象是否已經存在。
數據完整性：由於散列值是根據數據的內容來計算的，所以我們可以隨時通過Git來查看某一散列值是否與相關數據匹配。以檢測該數據上可能的意外變化或惡意操作。
自動重命名檢測：被重命名的文件可以被自動檢測到，因為根據該文件內容計算出的散列值並沒有發生變化。也正因為如此，Git中並沒有專用的重命名命令，隻需移動命令即可。

最後更新：2017-05-31 18:01:24

  上一篇：  《Git學習指南》——1.3　分支的創建與合並很簡單

  下一篇：  《Git學習指南》——第1章 基本概念 1.1分布式版本控製，有何過人之處