軟體配置管理過程是貫穿整個軟體開發週期的重要過程，為此，也誕生了許多著名的企業級工具，開源的CVS、SVN，企業級的ClearCase、PVCS。
由於財力有限，無法調研大型企業級軟體，但CVS和SVN對於目前的軟體開發，已顯得不是那麼的方便。在開源軟體領域，開源協作的開發過程，採取的種種成熟的開發模式，卻值得我們思考，於是我決定調研一下開源軟體專案開發中的配置管理工具。

這裡可以下載到本文的pdf版本:【百度雲網盤】

一、Git——分散式版本管理工具

Git本身並不能稱之為一個完整的配置管理工具，但在開源領域，卻是目前做的最好的版本管理工具。
Git的強大之處在於版本模型，採取的是直接記錄快照的方式，簡單明瞭。Git的版本管理類似於一個隨時間變化的檔案系統，每一個版本的具體內容，都會作為快照的一部分進行儲存，這樣的好處是，任意兩個版本間都能快速的進行差異比較，瞭解程式碼直接的不同。

為了減少資源佔用，如果檔案並未發生變化，那麼將不會被儲存，而且其對檔案的改動評估，是基於檔案的指紋資訊的，並非一般的系統時間戳，所以不會產生內容資訊的不一致等錯誤。

另外我比較喜歡使用Git的一點，其大部分操作都是在本地執行的，效率非常的高，而且你在沒有聯網的情況下，依舊可以進行版本管理，如果你要回復到以前的一個版本，它立即就可以將你當前的檔案變更為以前檔案的快照，十分方便快捷。這樣在很多情況下，都能輕鬆的工作。

Git的基本教程

開源軟體一般喜歡在linux下開發，我也使用了ubuntu14.04，那麼我將在此環境下說明git的使用方法

首先Git的安裝很簡單，只需在控制檯下鍵入：

sudo apt-get install git

如果你需要git的GUI介面，那麼還需要安裝：

sudo apt-get install git-gui

Git是有工作路徑的概念的，而我們的所有git指令，都作用於當前路徑所處的工作空間，在一個目錄下執行如下語句，將會將該目錄初始化為一個Git工作空間：

git init

這時，我們的倉庫目錄中會自動的產生一個“.git”資料夾，這個資料夾中會保留有Git的臨時檔案以及本地倉庫等
Git的工作空間大概是一個這樣的結構：

在Git中，每一個版本庫，都被稱為一個倉庫，倉庫有本地和遠端之分。Git初始化後，會為你構建一個本地倉庫，HEAD指向當前的開發分支，還會建立一個緩衝區Stage，供你臨時新增檔案，構成一次commit。Stash則是一個工作狀態儲存棧，用於儲存/恢復WorkSpace中的臨時狀態。

接下來，這個指令將新增檔案到緩衝區中：

git add <file name>

當然，你也可以使用如下指令將一個目錄的檔案都新增到緩衝區：

git add <path>

如果你覺得快取區中的檔案已經適合提交到本地倉庫中，稱為一個新的版本了，那麼你可以這樣將新版本提交到本地倉庫，當前工作的本地倉庫即HEAD所指向的倉庫，如果你的分支不對，可能需要分支切換：

git commit -m "commit message"

如果你有github賬戶，或者有一個遠端倉庫，那麼你還可以將這份程式碼同步到遠端倉庫中，我們稍後會介紹如何在github上使用git同步程式碼。

Git分支和倉庫

分支是Git的一個非常有用的特性，有很多軟體，在主要的框架寫好後，會有隔離開發的需要，在那些經典的CVS/Subversion管理工具的世界中，合併/分支被認為是有些嚇人的，而使用Git時，一切變得簡單，而且Git正是鼓勵你這樣做，儘量通過分支的設定，使得程式碼開發流程更加的清晰。

分支是用來將特性開發絕緣開來的。在你建立倉庫的時候，master 是“預設的”分支。下面我們將建立一個叫做“feature_x”的分支，並切換過去：

git checkout -b feature_x

切換回主分支：

git checkout master

要合併其他分支到你的當前分支（例如 master），執行：

git merge <branch>

但很不幸的是，不是所有的合併都不會帶來衝突，如果兩個人同時修改了一份程式碼，往往會造成難以合併，你需要手動修改衝突檔案，然後將他們重新添加回來以保證合併成功：

git add <conflicts file name>

一個成功的分支模式大概像這樣：

在很多情況下，我們往往不在意分支的管理，但這樣往往會給開源專案帶來種種問題，而一個設計合理的開源專案，往往可以很方便的多人協作來進行。
而下面我們將介紹一下，這個分支模型中，各個操作的流程和其對於開發過程的意義。

主分支和develop分支

我們會發現，從Github上籤下來的程式碼，基本上都能完美的直接構建執行，那麼是如何維護開發版本的呢？
一般我們都會像這樣，構建兩個分支：

• master分支
• develop分支

origin的master分支每個Git使用者都很熟悉。平行的另外一個分支叫做develop分支。
我們認為master分支上的每個版本的程式碼，都是可釋出的。而開發時切換到develop分支，在關鍵節點上，做好測試，確認無誤後，將會和master分支合併，然後打上釋出版本號的tag。對於這個操作，應該嚴格的把關，保障每個發行版的質量。

Feature分支

Feature分支（特性分支），是一種非常有用的輔助性分支，主要目標是幫助隊員間並行開發，每個人應該在不同的分支開發自己輔助的新特性，這樣能夠讓每個人的工作都是在一個非常明確的版本下進行。

如果不這樣操作，帶來的一個嚴重後果可能就是，某人的某個版本包含了未經測試的程式碼，而這份程式碼直接被提交到了develop分支中，那麼所有人的工作在程式碼更新後，反而都出現了問題，全體員工都在debug，會嚴重影響專案的進度。

新建分支，這就像將當前版本的程式碼放進了一個安全的實現沙箱，即使帶來問題，不會影響他人，但我們還是不推薦將自己的feature分支釋出到公共程式碼庫中，當然合作開發的時候除外。特性分支可以從develop分支拉取建立，最終必須合併會develop分支，只要特性還在開發，這個分支就應存在，但最終還是會被合併到develop中或被廢棄。

Release分支 和 Hotfix分支

Release分支是在新的版本快要釋出時，核心團隊應建立一個對應的Release-*分支，這個分支是用來在目前確定的軟體特性下，不再新增新特性，全力修復已有bug，將軟體除錯好並進行最終測試，打包釋出等工作。從develop分支拉取新的release分支的時間點是當開發工作已經達到了新版本的期望值。至少在這個時間點，下一版本準備釋出的所有目標特性必須已經合併到了develop分支。其餘不必要的特性可以先不合並，等特性測試無誤，再合併入develop分支，以免增加發布前的測試和除錯難度。

release分支建立好後，就確定了下一個版本號，以及該版本支援的新功能，我們可以在此更新軟體的新功能列表，進行測試和小修小補，構建釋出包和安裝包等工作。

在一切工作都以完成後，我們會將release分支合併回master分支，然後打上tag標記

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2

下面我們還需要將release分支的小修小改儲存，那麼需要將其合併至develop分支，但由於有些專案開發組還在工作，也可能更新了develop分支的程式碼，這步合併也有可能引入衝突。

$ git checkout develop
$ git merge --no-ff release-1.2

Hotfix分支往往也是臨時的輔助分支，用來臨時修復已有的問題，那麼我們可以臨時從一個有問題的釋出版中，新建一個hotfix分支，這個分支在簡單的修復bug後就會結束。

完成工作後，解決掉的bug程式碼需要合併回master分支，但同時也需要合併到develop分支，目的是保證在下一版中該bug已經被解決。當然，也有可能存在一些特殊情況，若當一個release分支存在時，hotfix 分支需要合併到release 分支，而不是develop分支，因為hotfix是緊急的，應該儘快被髮布。

上下游倉庫

有一些很大型的軟體，往往採取元件開發的方式，一個部件往往依賴一些別的部件，在他們開發的過程中，上下游的關係也是十分重要的。

Git可以很方便的新增自己關注的上游倉庫：

git remote add pb git://github.com/reponame.git

你也可以方便的獲取其最新版本

git fetch pb

同樣，你需要同步到你的遠端倉庫中，才能使別人看到你的更改，使用命令git push [remote-name] [branch-name]：

git push origin master

當然，你的更新不一定就成功，如果在你推送資料前，有其他人推送了更新，那麼你的更新將會失敗，你必須同步到最新版本，並與你當前的版本合併，你才能將該版本更新，同樣，在github的協作模型中，也有類似的問題，你在發PR時，如果有其他人先更新了，那麼你也要同步一下，你的更新才能被採納。

在一些生產環境中，甚至連美工都有自己的遠端倉庫，她們會將自己的設計圖上傳到美工的倉庫中，前端設計人員只要更新一下，就能知道她們是否有新的設計圖樣。