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

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

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

第1章 基本概念

在本章中，我們將介紹一個分布式版本控製係統的設計思路，以及它與集中式版本控製係統的不同之處。除此之外，我們還將帶你了解分布式版本庫的具體工作方式，以及為什麼我們會說，在Git中創建分支和合並分支不是個大不了的問題。

1.1　分布式版本控製，有何過人之處

在具體探討分布式版本控製的概念之前，讓我們先來快速回顧一下傳統的集中式版本控製架構。

圖1.1中所顯示的就是一個集中式版本控製係統（例如CVS或Subversion）的典型布局。每個開發者都在他或她自己的計算機上有一個包含所有項目文件的工作目錄（即工作區）。當該開發者在本地做了修改之後，他或她就會定期將修改提交給某台中央服務器。然後，開發者在執行更新操作的同時也會從該服務器上撿取出其他開發者所做的修改。這台中央服務器上存儲著這些文件（即版本庫）的當前版本和曆史版本。因此，這些被並行開發的分支，以及各種被命名（標記）的版本都將會被集中管理。

圖1.1　集中式版本控製

而在分布式版本控製係統（見圖1.2）中，開發者環境與服務器環境之間是沒有分隔的。每一個開發者都同時擁有一個用於當前文件操作的工作區與一個用於存儲該項目所有版本、分支以及標簽的本地版本庫（我們稱其為一份克隆）。每個開發者的修改都會被載入成一次次的新版本提交(commit), 首先提交到其本地版本庫中。然後，其他開發者就會立即看到新的版本。通過推送（push）和拉回（pull）命令，我們可以將這些修改從一個版本庫傳送到另一個版本庫中。這樣一來，從技術上來看，這裏所有的版本庫在分布式架構上的地位是同等的。因此從理論上來講，我們不再需要借助服務器，就可以將某一台開發工作機上所做的所有修改直接傳送給另一開發工作機。當然在具體實踐中，Git中的服務器版本庫也扮演了重要的角色，例如以下這些特型版本庫。

圖1.2　分布式版本控製

項目版本庫（blessed repository）：該版本庫主要用於存儲由“官方”創建並發行的版本。
共享版本庫（shared repository）：該版本庫主要用於開發團隊內人員之間的文件交換。在小型項目中，項目版本庫本身就可以勝任這一角色了。但在多點開發的條件下，我們可能就會需要幾個這樣的專用版本庫。
工作流版本庫（workflow repository）：工作流版本庫通常隻用於填充那些代表工作流中某種特定進展狀態的修改，例如審核通過後的狀態等。
派生版本庫（fork repository）：該版本庫主要用於從開發主線分離出某部分內容（例如，分離出那些開發耗時較長，不適合在一個普通發布周期中完成的內容），或者隔離出可能永遠不會被包含在主線中的、用於實驗的那部分開發進展。
下麵，我們再來看看分布式係統相對於集中式的優點有哪些。

高性能：幾乎所有的操作都無需進行網絡訪問，均可直接在本地執行。
高效的工作方式：開發者可通過多個本地分支在不同任務之間進行快速切換。
離線功能：開發者可以在沒有服務器連接的情況下執行提交、創建分支、版本標簽等操作。之後再將其上傳服務器。
靈活的開發進程：我們可以在團隊和公司中為其他部門建立專用的版本庫，例如為方便與測試人員交流而建的版本庫。這樣相關修改就很容易發布，因為隻是特定版本庫上的一次推送。
備份作用：由於每個開發者都持有一份擁有完整曆史版本的版本庫副本，所以因服務器故障而導致數據丟失的可能性是微乎其微的。
可維護性：對於那些難以對付的重構工作，我們可以在將成功傳送給其原始版本庫之前，先在該版本庫的副本上嚐試一下。

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

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

  下一篇：  《OpenStack實戰》——導讀