Git的強(qiáng)大是眾所周知的，本文要分享的是關(guān)于"使用Git的分支和合并功能來進(jìn)行版本管理的開發(fā)模型"。以下是譯文，原文地址

這篇文章我想介紹一下一年前就提到過的我所有項目(工作/私有)都在使用的開發(fā)模式，經(jīng)過事實驗證，確實非常可行。很早就想寫了，一直沒騰出時間。我不會涉及項目的細(xì)節(jié)，只是談?wù)劮种У氖褂貌呗院桶l(fā)布管理。

上圖是使用Git這個版本控制工具來管理所有源碼的。

為什么使用Git

如果要看詳細(xì)的Git與集中式源碼管理工具的優(yōu)勢與劣勢，可以參見這篇文章，那里有很多口水仗。作為一個開發(fā)人員，所有的源碼管理工具中，我最喜歡Git。Git從根本上改變了開發(fā)人員對分支和合并的使用，傳統(tǒng)的CVS/SVN，分支和合并都是高級話題，而且使用起來稍顯麻煩，隔一段時間才會用一次。但是有了Git，這些操作就成了家常便飯。

由于使用簡單，方便重復(fù)操作，分支和合并不再是讓人望而生畏的操作，版本管理工具應(yīng)該盡可能地對分支/合并提供最好的支持。

工具談得差不多了，回到開發(fā)上。我待會要講到的模型其實是一些每個開發(fā)人員都應(yīng)該遵守的步驟，如果想管理好軟件的開發(fā)流程的話。

分布式但集中化

我們要使用的倉庫是一個"中心庫"，當(dāng)然這個中心庫只是被認(rèn)為是這樣(因為Git是分布式的，從技術(shù)層面上來說是沒有中心庫的)，我們將把這個倉庫叫做"origin"，因為Git用戶都熟悉這個名字。

每個開發(fā)者pull和push到origin，但除了中心化的push-pull關(guān)系外，每個開發(fā)者還可以從其他開發(fā)者那pull changes。比如說，對于一個比較大的新特性，在把代碼提交到origin之前，很可能會安排2個或多個開發(fā)者。上圖中有幾個小團(tuán)隊：Alice和 Bob，Alice和David，Clair和David。

從技術(shù)角度來說，其實就是Alice定義了一個叫Bob的Git remote，指向到Bob的倉庫。

main分支

中心倉庫有兩個分支：

• master
• develop

origin上的master分支，Git用戶應(yīng)該很熟悉，跟master并行的有一個develop分支

我們把origin/master作為主要分支，源碼的HEAD總是表示production-ready(可隨時部署)狀態(tài)。而origin/develop上的代碼是為下一次的代碼發(fā)布準(zhǔn)備的。每日構(gòu)建也是基于此分支。

當(dāng)develop分支達(dá)到了一個穩(wěn)定狀態(tài)并準(zhǔn)備發(fā)布時，所有的改變都要合并到master分支，并標(biāo)上版本號。如何實現(xiàn)的下面細(xì)說。

這樣每次與master合并都會有新的部署發(fā)布。這點(diǎn)可以自動化，如使用Git hook腳本來實現(xiàn)自動部署代碼到線上。

支持(supporting)分支

我們的開發(fā)模型使用了一些支持分支放在master和develop分支的旁邊，方便開發(fā)小組之間的并行開發(fā)。不像main分支，這些分支是有時間限制的，因為他們最終都會被移除。

我們會使用到的不同的分支

• Feature branches
• Release branches
• Hotfix branches

每個分支都有各自的作用，并且有嚴(yán)格的規(guī)定，如：只能從哪個分支上去新開分支，只能合并到那個分支。這個待會細(xì)說。

Feature branches

繼承分支: develop
合并分支：develop
命名規(guī)范：除了master,develop,release-,hotfix-

Feature branches是用來開發(fā)新特性的(短期，遠(yuǎn)期都可以)。當(dāng)開始開發(fā)新特性時，很可能不知道這個特性會出現(xiàn)在哪個目標(biāo)版本。一旦開發(fā)完成就可以合并到develop，當(dāng)然如果開發(fā)失敗，就可以拋棄。

創(chuàng)建一個 Feature branch

當(dāng)要創(chuàng)建一個新特性時，從develop分支上再進(jìn)行分支

$ git checkout -b myfeature develop Switched to a new branch "myfeature" 

新特性完成時，可以合并到develop

$ git checkout develop Switched to branch 'develop' 
$ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) 
$ git branch -d myfeature Deleted branch myfeature (was 05e9557). 
$ git push origin develop 

—no-ff (譯者注：no fast foward)標(biāo)簽，使得每一次的合并都創(chuàng)建一個新的commit記錄。即使這個commit只是fast-foward，這樣可以避免丟失信息

不幸的是，我沒有找到讓—no-ff成為commit默認(rèn)參數(shù)的方法(譯者注：修改.consolerc?)，但確實應(yīng)該提供一個方法。

Release branch

繼承分支: develop
合并分支：develop 和 master
命名規(guī)范：release-*

Release branch 是為新的production release準(zhǔn)備的(譯者注：相當(dāng)于RC版)，可以有一些小的bug，并為發(fā)布準(zhǔn)備一些元數(shù)據(jù)(版本號，構(gòu)建日期等等)。把所有的這些工作都放到 Release branch，develop branch就能更清晰地知道下一個版本要開發(fā)哪些特性。

從develop分支合并到release分支的關(guān)鍵因素是:develop分支達(dá)到了release分支所要求的狀態(tài)。至少所有針對該release的特性要被合并。至于那些將來會有的特性可以先放一放。然后就是為接下來即將要發(fā)布的版本分配一個版本號。

創(chuàng)建一個Release branch

Release branch是通過develop分支而創(chuàng)建。舉個例子，假如1.1.5是當(dāng)前的production release，然后會有一個比較大的版本發(fā)布。develop的狀態(tài)已經(jīng)可以發(fā)布版本了，經(jīng)過商榷后，決定發(fā)布為1.2版本(而不是1.1.6或 2.0)，所以我們創(chuàng)建一個release分支，并給這個分支一個新的版本號

$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" 
$ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. 
$ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-) 

這個新分支可能會存在一定的時間，直到可以被合并到production branch。這段時間內(nèi)，bug修補(bǔ)可以在這個分支上進(jìn)行(而不是develop分支)。添加新特性(尤其比較大的)是不允許的。最后還是要被合并到 develop，然后繼續(xù)在develop分支上開發(fā)，直到下一個版本。

完成一個release branch

當(dāng)release branch已經(jīng)準(zhǔn)備就緒，需要做幾件事。首先，release分支被合并到master分支上(每一個提交到master上的commit都是一個新版 本，切記)。然后master上的commit都要添加tag，方便將來查看和回滾。最后release上所做的修改必須合并到develop分支上，保 證bug已被修補(bǔ)。

前兩個步驟：

$ git checkout master Switched to branch 'master' 
$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) 
$ git tag -a 1.2 

為了把release上的改變保存到develop，我們需要合并到develop

$ git checkout develop Switched to branch 'develop' 
$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) 

這個步驟可能會導(dǎo)致沖突，如果這樣的話，解決沖突，然后再提交。

現(xiàn)在一切都完成了，可以把release branch干掉了。

$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe). 

Hotfix branch

繼承分支: master
合并分支：develop 和 master
命名規(guī)范：hotfix-*

Hotfix branch和Release branch有幾分相似，都是為了新的production release而準(zhǔn)備的。比如運(yùn)行過程中發(fā)現(xiàn)了bug，就必須快速解決，這時就可以創(chuàng)建一個Hotfix branch，解決完后合并到master分支上。好處是開發(fā)人員可以繼續(xù)工作，有專人來負(fù)責(zé)搞定這個bug。

創(chuàng)建Hotfix branch

Hotfix是從master分支上創(chuàng)建的。假如當(dāng)前運(yùn)行版本是1.2，然后發(fā)現(xiàn)有bug，但是develop還在開發(fā)中，不太穩(wěn)定，這時就可以新開一個Hotfix branch，然后開始解決問題。

$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" 
$ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1. 
$ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-) 

解決問題，一次或幾次commit

$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-) 

完成Hotfix branch

當(dāng)結(jié)束時，bugfix要被合并到master，同時也要合并到develop，保證下個版本發(fā)布時該bug已被修復(fù)。這跟release branch完成時一樣。

首先更新master和tag release

$ git checkout master Switched to branch 'master' 
$ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) 
$ git tag -a 1.2.1 

接下來與develop合并

$ git checkout develop Switched to branch 'develop' 
$ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) 

有一個例外，就是當(dāng)一個release branch存在時，bugfix要被合并到release而不是develop，因為release最終會被合并到develop。

最后移除branch

$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6). 

總結(jié)

這個開發(fā)模型其實沒有什么新穎的，一開始提到的"大圖"確實在我們的項目起到了非常大的作用。這是很優(yōu)雅的一個模型，很容易實現(xiàn)，也容易在團(tuán)隊成員之間達(dá)成一致。

PS:需要這個模型大圖的，可以去原文地址下載

若無特別說明，本站文章均為原創(chuàng)，轉(zhuǎn)載請保留鏈接，謝謝