Git分布式版本控制介紹

一、Git VS SVN

從管理流程上看Git是分布式的，而SVN是集中式的管理方式。

二、集中式 VS 分布式

1、集中式管理

集中式管理的工作流程：

集 中式代碼管理的核心是服務器，所有開發者在開始新一天的工作之前必須從服務器獲取代碼，然后開發，最后解決沖突，提交。所有的版本信息都放在服務器上。如 果脫離了服務器，開發者基本上是不可以工作的。可惡的是在我們項目中，每個人都是直接在trunk上開發的，沒有建立自己的分支，這樣沖突發生很頻繁，有 時甚至會發生覆蓋現象，花費在這上面的時間估計占工作時間的0.05

缺點：

1、服務器壓力太大，數據庫容量暴增。

2、如果不能連接到服務器上，基本上不可以工作，看上面第二步，如果服務器不能連接上，就不能提交，還原，對比等等。

3、不適合開源開發（開發人數非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的權限管理機制（例如分支訪問限制），可以實現分層管理，從而很好的解決開發人數眾多的問題。

優點：

1、管理方便，邏輯明確，符合一般人思維習慣。

2、易于管理，集中式服務器更能保證安全性。

3、代碼一致性非常高。

4、適合開發人數不多的項目開發。

5、大部分軟件配置管理的大學教材都是使用svn 和vss。

2、分布式管理

分布式管理的工作流程：

分布式和集中式的最大區別在于開發者可以在本地提交。每個開發者機器上都有一個服務器的數據庫。

Git開發步驟：

一般開發者的角度：

1：從服務器上克隆數據庫（包括代碼和版本信息）到單機上。

2：在自己的機器上創建分支，修改代碼。

3：在單機上自己創建的分支上提交代碼。

4：在單機上合并分支。

5：新建一個分支，把服務器上最新版的代碼fetch下來，然后跟自己的主分支合并。

6：生成補丁（patch），把補丁發送給主開發者。

7：看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然后再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。

8：一般開發者之間解決沖突的方法，開發者之間可以使用pull命令解決沖突，解決完沖突之后再向主開發者提交補丁。

主開發者的角度（假設主開發者不用開發代碼）：

1：查看郵件或者通過其它方式查看一般開發者的提交狀態。

2：打上補丁，解決沖突（可以自己解決，也可以要求開發者之間解決以后再重新提交，如果是開源項目，還要決定哪些補丁可用，哪些不用）。

3：向公共服務器提交結果，然后通知所有開發人員。

優點：

適合分布式開發，強調個體。

公共服務器壓力和數據量都不會太大。

速度快、靈活。

任意兩個開發者之間可以很容易的解決沖突。

缺點：

資料少（起碼中文資料很少）。

學習周期相對而言比較長。

不符合常規思維。

代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。

三、git常用命令介紹

git init

創建一個數據庫

git clone

復制一個數據到制定文件夾

git add 和git commit

把想提交的文件add上，然后commit這些文件到本地數據庫。

git pull

從服務器下載數據庫，并跟自己的數據庫合并。

git fetch

從服務器下載數據庫，并放到新分支，不跟自己的數據庫合并。

git whatchanged

查看兩個分支的變化

git branch

創建分支，查看分支，刪除分支

git checkout

切換分支

git merge

合并分支，把目標分支合并到當前分支

git config

配置相關信息，例如email和name

git log

查看版本歷史

git show

查看版本號對于版本的歷史，如果參數是HEAD查看最新版本。

git tag

標定版本號

git reset

恢復到之前的版本

--mixed是git-reset的默認選項，它的作用是重置索引內容，將其定位到指定的項目版本，而不改變你的工作樹中的所有內容，只是提示你有哪些文件還未更新。

--soft選項既不觸動索引的位置，也不改變工作樹中的任何內容。該選項會保留你在工作樹中的所有更新并使之處于待提交狀態。相當于在--mixed基礎上加上git add。

--hard 把整個目錄還原到一個版本，包括所有文件。

git push

向其他數據庫推送自己的數據庫

git status

顯示當前的狀態

git mv

重命名文件或者文件夾

git rm

刪除文件或者文件夾

git help

查看幫助，還有幾個無關緊要的命令，請自己查看幫助。

四、git開發模式

1、大項目開發模式（如圖4.1）

對于項目負責人

1：初始化

對于最終項目負責人：

使用git init --bare在公共服務器上建立一個空數據庫，在自己的機器上通過

或者數據庫（這里需要設置一下訪問權限，由于git沒有提供權限管理功能，所以要通過ssh設置，具體是對下一級子項目項目可讀不可寫，對自己可讀可寫）。

新建一些必要的文件夾和文件放到自己的數據庫上

然后使用

提交到公共服務器上，作為原始版本。

告訴下級公共服務器的地址。

對于子項目負責人：

在子公共服務器上克隆一個數據庫

設置訪問權限，對下級可讀不可寫，對自己可讀可寫。
在自己的計算機中克隆一個數據庫

告訴下級子公共服務器地址。

對于最底層的開發人員：
在上級公共服務器中克隆一個數據庫

2：開展工作
對于最終項目負責人
收來自下級的郵件
在自己的數據庫上建分支，并轉到分支上

重復上述步驟，直到所有補丁打完。

如果發現在合并分支的時候發現有些沖突需要下級項目負責人協助解決的話，可以通知下級項目負責人。

對于子項目負責人：
如果上級項目負責人需要他們之間合作解決某些沖突，他們可以通過

解決沖突。
如果上級項目負責人沒有要求合作解決沖突，那項目負責人應該做以下事情：

然后項目負責人就開始接收郵件，然后打補丁

重復上述工作，直到補丁全部打完。

下面是向上級提交更新的過程

對于最底層的開發人員：

如果上級要求解決沖突，同樣是要解決沖突，然后再提交補丁

如果不用，就從上級服務器更新

然后建分支，并開發代碼

然后是向上級提交代碼

2、實驗室模式

以上是git在大項目開發中的應用。

但是明顯是不適合我們實驗室的。

原因有三：

1、我們學生中沒有專門的維護人員。

2、我們學生中沒有對全局都很了解架構師。

3、我們的老師可以擔當此重任也只有我們的老師有這樣的實力，但是老師太忙，沒時間每天做這些瑣事。

所以我們需要一種新的合作模式（一種沒有項目負責人的模式）。

這種模式對開發人員的素質要求很高。

合作模式如下圖（圖4.2）：（適合我們實驗室使用）

這種模式的開發流程如下：
1、由其中一個開發者這服務器上建立一個數據庫。
所有開發者都可以向數據庫提交和下載東西，這里必須規定一定的時間間隔（一周或者一天）必須提交一次，不然以后解決沖突時是個大問題。
如果每個人的開發耦合度很高，我們可在服務器上建立分支，然后每人每次提交到自己的分支上，過一段時間之后（不能太久）有一個人去合并分支。然后所有人更新自己的數據庫的master分支，使之跟服務器上的master分支同步。
2、這樣服務器會有非常多的版本信息，集合了每個人的版本信息。
過了一段時間之后，例如有里程碑的出現。再由一個人把所有改動打補丁到最終服務器上。這樣最終服務器的版本信息就會很精練。
3、當我們的服務器無限膨脹到一定程度的時候我們可以把它刪除，然后用最終服務器上的一個版本作為起始版本。