Git的強(qiáng)大是眾所周知的，本文要分享的是關(guān)于"使用Git的分支和合并功能來(lái)進(jìn)行版本管理的開(kāi)發(fā)模型"。以下是譯文，原文地址
這篇文章我想介紹一下一年前就提到過(guò)的我所有項(xiàng)目(工作/私有)都在使用的開(kāi)發(fā)模式，經(jīng)過(guò)事實(shí)驗(yàn)證，確實(shí)非常可行。很早就想寫(xiě)了，一直沒(méi)騰出時(shí)間。我不會(huì)涉及項(xiàng)目的細(xì)節(jié)，只是談?wù)劮种У氖褂貌呗院桶l(fā)布管理。
上圖是使用Git這個(gè)版本控制工具來(lái)管理所有源碼的。
為什么使用Git
如果要看詳細(xì)的Git與集中式源碼管理工具的優(yōu)勢(shì)與劣勢(shì)，可以參見(jiàn)這篇文章，那里有很多口水仗。作為一個(gè)開(kāi)發(fā)人員，所有的源碼管理工具中，我最喜歡Git。Git從根本上改變了開(kāi)發(fā)人員對(duì)分支和合并的使用，傳統(tǒng)的CVS/SVN，分支和合并都是高級(jí)話題，而且使用起來(lái)稍顯麻煩，隔一段時(shí)間才會(huì)用一次。但是有了Git，這些操作就成了家常便飯。
由于使用簡(jiǎn)單，方便重復(fù)操作，分支和合并不再是讓人望而生畏的操作，版本管理工具應(yīng)該盡可能地對(duì)分支/合并提供最好的支持。
工具談得差不多了，回到開(kāi)發(fā)上。我待會(huì)要講到的模型其實(shí)是一些每個(gè)開(kāi)發(fā)人員都應(yīng)該遵守的步驟，如果想管理好軟件的開(kāi)發(fā)流程的話。
分布式但集中化
我們要使用的倉(cāng)庫(kù)是一個(gè)"中心庫(kù)"，當(dāng)然這個(gè)中心庫(kù)只是被認(rèn)為是這樣(因?yàn)镚it是分布式的，從技術(shù)層面上來(lái)說(shuō)是沒(méi)有中心庫(kù)的)，我們將把這個(gè)倉(cāng)庫(kù)叫做"origin"，因?yàn)镚it用戶都熟悉這個(gè)名字。
每個(gè)開(kāi)發(fā)者pull和push到origin，但除了中心化的push-pull關(guān)系外，每個(gè)開(kāi)發(fā)者還可以從其他開(kāi)發(fā)者那pull changes。比如說(shuō)，對(duì)于一個(gè)比較大的新特性，在把代碼提交到origin之前，很可能會(huì)安排2個(gè)或多個(gè)開(kāi)發(fā)者。上圖中有幾個(gè)小團(tuán)隊(duì)：Alice和 Bob，Alice和David，Clair和David。
從技術(shù)角度來(lái)說(shuō)，其實(shí)就是Alice定義了一個(gè)叫Bob的Git remote，指向到Bob的倉(cāng)庫(kù)。
main分支
中心倉(cāng)庫(kù)有兩個(gè)分支：
origin上的master分支，Git用戶應(yīng)該很熟悉，跟master并行的有一個(gè)develop分支
我們把origin/master作為主要分支，源碼的HEAD總是表示production-ready(可隨時(shí)部署)狀態(tài)。而origin/develop上的代碼是為下一次的代碼發(fā)布準(zhǔn)備的。每日構(gòu)建也是基于此分支。
當(dāng)develop分支達(dá)到了一個(gè)穩(wěn)定狀態(tài)并準(zhǔn)備發(fā)布時(shí)，所有的改變都要合并到master分支，并標(biāo)上版本號(hào)。如何實(shí)現(xiàn)的下面細(xì)說(shuō)。
這樣每次與master合并都會(huì)有新的部署發(fā)布。這點(diǎn)可以自動(dòng)化，如使用Git hook腳本來(lái)實(shí)現(xiàn)自動(dòng)部署代碼到線上。
支持(supporting)分支
我們的開(kāi)發(fā)模型使用了一些支持分支放在master和develop分支的旁邊，方便開(kāi)發(fā)小組之間的并行開(kāi)發(fā)。不像main分支，這些分支是有時(shí)間限制的，因?yàn)樗麄冏罱K都會(huì)被移除。
我們會(huì)使用到的不同的分支
- Feature branches
- Release branches
- Hotfix branches
每個(gè)分支都有各自的作用，并且有嚴(yán)格的規(guī)定，如：只能從哪個(gè)分支上去新開(kāi)分支，只能合并到那個(gè)分支。這個(gè)待會(huì)細(xì)說(shuō)。
Feature branches
繼承分支: develop
合并分支：develop
命名規(guī)范：除了master,develop,release-,hotfix-
Feature branches是用來(lái)開(kāi)發(fā)新特性的(短期，遠(yuǎn)期都可以)。當(dāng)開(kāi)始開(kāi)發(fā)新特性時(shí)，很可能不知道這個(gè)特性會(huì)出現(xiàn)在哪個(gè)目標(biāo)版本。一旦開(kāi)發(fā)完成就可以合并到develop，當(dāng)然如果開(kāi)發(fā)失敗，就可以拋棄。
創(chuàng)建一個(gè) Feature branch
當(dāng)要?jiǎng)?chuàng)建一個(gè)新特性時(shí)，從develop分支上再進(jìn)行分支
$ git checkout -b myfeature develop Switched to a new branch "myfeature"
新特性完成時(shí)，可以合并到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)建一個(gè)新的commit記錄。即使這個(gè)commit只是fast-foward，這樣可以避免丟失信息
不幸的是，我沒(méi)有找到讓—no-ff成為commit默認(rèn)參數(shù)的方法(譯者注：修改.consolerc?)，但確實(shí)應(yīng)該提供一個(gè)方法。
Release branch
繼承分支: develop
合并分支：develop 和 master
命名規(guī)范：release-*
Release branch 是為新的production release準(zhǔn)備的(譯者注：相當(dāng)于RC版)，可以有一些小的bug，并為發(fā)布準(zhǔn)備一些元數(shù)據(jù)(版本號(hào)，構(gòu)建日期等等)。把所有的這些工作都放到 Release branch，develop branch就能更清晰地知道下一個(gè)版本要開(kāi)發(fā)哪些特性。
從develop分支合并到release分支的關(guān)鍵因素是:develop分支達(dá)到了release分支所要求的狀態(tài)。至少所有針對(duì)該release的特性要被合并。至于那些將來(lái)會(huì)有的特性可以先放一放。然后就是為接下來(lái)即將要發(fā)布的版本分配一個(gè)版本號(hào)。
創(chuàng)建一個(gè)Release branch
Release branch是通過(guò)develop分支而創(chuàng)建。舉個(gè)例子，假如1.1.5是當(dāng)前的production release，然后會(huì)有一個(gè)比較大的版本發(fā)布。develop的狀態(tài)已經(jīng)可以發(fā)布版本了，經(jīng)過(guò)商榷后，決定發(fā)布為1.2版本(而不是1.1.6或 2.0)，所以我們創(chuàng)建一個(gè)release分支，并給這個(gè)分支一個(gè)新的版本號(hào)
$ 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(-)
這個(gè)新分支可能會(huì)存在一定的時(shí)間，直到可以被合并到production branch。這段時(shí)間內(nèi)，bug修補(bǔ)可以在這個(gè)分支上進(jìn)行(而不是develop分支)。添加新特性(尤其比較大的)是不允許的。最后還是要被合并到 develop，然后繼續(xù)在develop分支上開(kāi)發(fā)，直到下一個(gè)版本。
完成一個(gè)release branch
當(dāng)release branch已經(jīng)準(zhǔn)備就緒，需要做幾件事。首先，release分支被合并到master分支上(每一個(gè)提交到master上的commit都是一個(gè)新版 本，切記)。然后master上的commit都要添加tag，方便將來(lái)查看和回滾。最后release上所做的修改必須合并到develop分支上，保 證bug已被修補(bǔ)。
前兩個(gè)步驟：
$ 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)
這個(gè)步驟可能會(huì)導(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)行過(guò)程中發(fā)現(xiàn)了bug，就必須快速解決，這時(shí)就可以創(chuàng)建一個(gè)Hotfix branch，解決完后合并到master分支上。好處是開(kāi)發(fā)人員可以繼續(xù)工作，有專人來(lái)負(fù)責(zé)搞定這個(gè)bug。
創(chuàng)建Hotfix branch
Hotfix是從master分支上創(chuàng)建的。假如當(dāng)前運(yùn)行版本是1.2，然后發(fā)現(xiàn)有bug，但是develop還在開(kāi)發(fā)中，不太穩(wěn)定，這時(shí)就可以新開(kāi)一個(gè)Hotfix branch，然后開(kāi)始解決問(wèn)題。
$ 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(-)
解決問(wèn)題，一次或幾次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é)束時(shí)，bugfix要被合并到master，同時(shí)也要合并到develop，保證下個(gè)版本發(fā)布時(shí)該bug已被修復(fù)。這跟release branch完成時(shí)一樣。
首先更新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
接下來(lái)與develop合并
$ git checkout develop Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes)
有一個(gè)例外，就是當(dāng)一個(gè)release branch存在時(shí)，bugfix要被合并到release而不是develop，因?yàn)閞elease最終會(huì)被合并到develop。
最后移除branch
$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).
總結(jié)
這個(gè)開(kāi)發(fā)模型其實(shí)沒(méi)有什么新穎的，一開(kāi)始提到的"大圖"確實(shí)在我們的項(xiàng)目起到了非常大的作用。這是很優(yōu)雅的一個(gè)模型，很容易實(shí)現(xiàn)，也容易在團(tuán)隊(duì)成員之間達(dá)成一致。
PS:需要這個(gè)模型大圖的，可以去原文地址下載
--EOF--
若無(wú)特別說(shuō)明，本站文章均為原創(chuàng)，轉(zhuǎn)載請(qǐng)保留鏈接，謝謝