第1章 Git的版本控制之道

版本控制系統（Version Control System，VCS）能夠幫助咱們記錄和跟蹤項目中各文件內容的修改變化。

    

1.1 版本庫

版本庫（Repository）是版本控制系統用來存儲全部歷史數據的地方。

   

集中式版本庫（Centralized Repository）——全部的程序員都會把他們的改動提交到服務器上的一個公共版本庫中。具體來講，每個程序員在本地有一個工做目錄樹，其內容是該版本庫中最新的代碼。

集中式版本庫的侷限性：

• 首先，在本地工做目錄樹中，只能看到代碼的最新版本。若是想查詢歷史修改記錄，就必須與服務器上的版本庫打交道。
• 其次，同遠程的版本庫鏈接，一般需要使用網絡。

   

使用分佈式版本控制系統（Distributed version control system，DVCS），每一個人都會在本地有本身的版本庫，而不是鏈接到服務器上的一個公共的版本庫。全部的歷史記錄都存儲在本地的版本庫中。向版本庫提交代碼無須鏈接遠程版本庫，而是記錄在本地的版本庫中。

   

1.2 版本庫中存儲什麼

項目開發所必需的全部內容：

• 項目源代碼
• 構建文件（Makefile、Rakefile及Ant的build.xml等）
• 配置文件樣例
• 各種文檔
• 程序使用的圖片
• 單元測試腳本等

例外：

項目中使用的開發工具，一般不用放到版本控制中去。

   

1.3 工做目錄樹

工做目錄樹（Working Tree），也就是程序員進行程序開發的地方。

工做目錄樹是版本庫的一個"斷面視圖"。它包括了開發該項目所須要的所有文件，包括源代碼文件、構建文件、單元測試文件等。一些版本控制系統把工做目錄樹稱爲工做拷貝（Working Copy）。

在Git中，版本庫不在服務器上，而存儲在本地工做目錄樹的".git"目錄中。這意味着，要想知道歷史信息，只和本地的版本庫打交道便可，無須與服務器上的版本庫通訊。

   

工做目錄樹的建立

• 第一個方法是用Git相關命令初始化版本庫，也就是生成".git"目錄，因而".git"目錄的父目錄就成了工做目錄樹。
• 第二個方法是克隆（Clone）一個已有的版本庫，也就連帶建立了相應的工做目錄樹。克隆一個已有的版本庫，就是建立該版本庫的一個拷貝，並把版本庫中主分支（Master Branch）的內容檢出（Check out）到工做目錄樹。

在Git中，檢出是指把工做目錄樹更新，使其內容與版本庫中某個特定的歷史版本相同。

   

1.4 代碼修改與文件同步

在修改了文件內容以後，需要進行單元測試以保證此次修改不會有任何負面影響，而後提交（Commit）這些改動。

每次提交操做都使得版本庫中新增一個版本（Revision）。除了記錄改動內容自己外，版本庫還記錄改動的日誌信息（Log Message）或稱提交留言（Commit Message），以便未來可以很方便地查詢爲何要作這個改動，並可以很方便地查找某個缺陷是什麼時候引入的。

   

使用像Git這樣的分佈式版本控制系統時，除了把改動提交到本地版本庫以外，還要經過某種方式將改動共享，以便其餘程序員可以獲得。所以，需要把改動推入（Push）到上游版本庫（upstream repository）。

上游版本庫是一個公共版本庫。通常來講，程序員們都把本身的改動推入到這裏。

這裏所說的推入，是指把本身鎖在版本庫中的內容，推入帶另外一個版本庫中。把改動推入公共版本庫後，其餘程序員就能"看到"了。

   

把遠程版本庫中的改動拿到本地版本庫中，須要兩步操做。

• 第一步，把改動取來（Fetch），把遠程版本庫中的版本和分支複製到本地版本庫中。這有點像是推入操做的反操做：推入操做時把本地版本庫中的改動發送給另外一個版本庫，而取來操做是把遠程版本庫中的改動取到本地版本庫中。
• 第二步，在本地版本庫中，把從遠程版本庫裏取來的改動與本身本地的改動合併（Merge）。Git工具包提供了這樣的合併工具。

通常來講，取來操做額合併操做老是前後執行的。所以，在Git中能夠用一個命令完成這兩步操做：拖入（Pull）。

   

1.5 跟蹤項目、目錄和文件

Git記錄和跟蹤版本庫中組成文件的各部份內容。Git並不把整個文件做爲不可分的總體來記錄和跟蹤，而是記錄和跟蹤組成該文件的各部份內容，也就是若干字符和代碼行（它們構成了變量和函數）。Git爲這些內容添加一系列元數據，好比所在文件的文件名、文件屬性，以及該文件是否爲符號連接等。

這樣作具備許多優點：

• 首先，它能顯著下降版本庫存儲所有歷史版本所需的磁盤空間。
• 其次，它使得"判斷某個函數或類在文件間移動和拷貝的狀況"之類的操做變得快捷容易。

   

而對這些文件的修改操做，則與尋常無異。全部的修改都在工做目錄樹中完成。工做目錄樹由目錄和文件組成，它們是版本庫中的一個"斷面視圖"。

版本庫中的文件和目錄結構的組織方式是對應於實際項目的。大部分項目遵循特定的目錄組織結構。Git自己並不規定如何在版本庫中組織這些模塊。Git支持任意的組織方式。

   

1.6 使用標籤跟蹤里程碑

使用標籤可以記錄下版本庫在特定歷史時刻的"斷面視圖"，以便於往後查找和恢復。

標籤以一個簡單的名稱（即標籤名）來標記版本庫歷史中某個特定的點。

本質上，標籤是一個對於使用者來講易於理解易於記憶的名字，用來標識版本庫中一個難讀難記的內部版本號，以此幫助使用者跟蹤版本歷史。

   

1.7 使用分支來跟蹤並行演進

上圖展現了分支原理。主分支（Master Branch）是研發的主線。

一些版本控制工具也把主分支稱做主幹（trunk）。

分支能夠長期存在，也能夠僅存在數小時。分支能夠合併到別的分支，但並不是全部的分支都必須合併。

有些狀況下，分支不該該合併，譬如用分支來記錄項目的不一樣發佈版本的開發時；用分支來記錄試驗性的工做時也是這樣，也許試驗結束後分支就刪除了。

分支也能夠在本地建立，並留做私用。建立本地分支並留做私用是有意義的。在完成試驗性的工做後，若是有價值，再讓你們拿到也不遲，而若是沒價值，那就把它消無聲息地刪除。

   

1.8 合併

合併操做把兩條或兩條以上的分支合併到一塊兒。

Git會自動處理分支合併，當Git不能自動合併時，就會提示衝突（conflict）。Git有好幾種解決衝突的方法。

Git也提供自動記錄和跟蹤合併的功能，稱爲合併跟蹤（merge tracking）。

   

1.9 鎖機制

當程序員從版本庫檢出某個文件時，版本庫禁止任何其餘人修改這個文件，直到該程序員撿入（check in）爲止。這種鎖機制稱爲嚴格鎖（strict locking）。

另外一種鎖機制，樂觀鎖（optimistic locking），容許多個程序員同時修改同一文件。樂觀鎖機制基於一個假定：大多數時候，這種併發修改不會引發衝突。