gib教程欄目介紹代碼分支管理模型

推薦（免費(fèi)）：gib教程

就像人心散，隊(duì)伍不好帶一樣，代碼版本多，分支也不好管

當(dāng)產(chǎn)品開(kāi)發(fā)到一定程度后，多版本同時(shí)開(kāi)發(fā)，各種熱修復(fù)等等問(wèn)題，勢(shì)必會(huì)帶來(lái)版本分支管理的問(wèn)題。今天我們準(zhǔn)備一起來(lái)看看第一種代碼分支管理方案。

這里要先強(qiáng)調(diào)一下，分支管理的方式各有千秋，不存在誰(shuí)一定比誰(shuí)好，只有誰(shuí)比誰(shuí)更適合你而已

熱門的成功代碼分支管理

這款人們的分支管理方案只要是從這篇叫A Successful Git Branching Model 衍生出來(lái)的。很多企業(yè)的項(xiàng)目都是采用這種方式來(lái)進(jìn)行管理。下面這張圖涵蓋了這種方式的各種分支設(shè)計(jì)：

A successful Git Branching Model

這個(gè)模型基本能滿足企業(yè)項(xiàng)目開(kāi)發(fā)過(guò)程中遇到的各種代碼版本管理的需求，下面嘗試著把這種模型分解給大家講講：

咬住青山不放松

在上面的圖中，大家可以看到有兩個(gè)分支的名字被加粗了：master 和 develop，這兩個(gè)是分支當(dāng)中的中流砥柱。

master

這是新建一個(gè)GIT repository之后的第一個(gè)分支。在這個(gè)模型中，master分支代表的是當(dāng)前產(chǎn)品線上的版本，它的最后一個(gè)commit可能是已經(jīng)上線了，或者已經(jīng)經(jīng)過(guò)QA/PD/PO 千萬(wàn)次折磨、分分鐘可以上線的功能。換句話說(shuō)，這條分支要做到 隨時(shí)都可以上線的！ 要是誰(shuí)把一個(gè)開(kāi)發(fā)了一般的功能提交到這個(gè)版本上去，有可能會(huì)被PO拉去祭天的！ 所以如果有嚴(yán)格的權(quán)限管理的話，一般會(huì)把這個(gè)分支給鎖起來(lái)，有且僅有上線的同事才有權(quán)限動(dòng)它！

另外master的每次上線都會(huì)打一個(gè)tag，表明版本號(hào)是多少

develop

一般靈長(zhǎng)類動(dòng)物都敬畏祭天這樣的操作，所以我們需要開(kāi)辟一篇新天地來(lái)大有作為。為了和大部隊(duì)保持一致，develop的分支是基于master創(chuàng)建出來(lái)的

C:githomegithubgitdou (master) (gitdou@0.1.0) λ git branch * master  C:githomegithubgitdou (master) (gitdou@0.1.0) λ git checkout -b develop Switched to a new branch 'develop'  C:githomegithubgitdou (develop) (gitdou@0.1.0) λ git show-branch -a --no-name * [develop] add httpUtil.js  ! [master] add httpUtil.js   ! [origin/HEAD] add httpUtil.js    ! [origin/master] add httpUtil.js ----

最后的git show-branch -a --no-name 命令的輸出可以看到develop的分支是基于master創(chuàng)建出來(lái)的

如果項(xiàng)目不是特別大，版本管理也比較簡(jiǎn)單，那么master跟develop這兩個(gè)分支就基本夠用了

文體兩開(kāi)花

當(dāng)項(xiàng)目稍微大一些的時(shí)候，會(huì)遇到各種各樣的版本管理需求，但不一定每一種你都需要，當(dāng)需要的時(shí)候可以再建立這些分支，比如有features, release, hotfix

features

第一種情況比較常見(jiàn)，項(xiàng)目有很多同事并行開(kāi)發(fā)，比如分了多模塊給多個(gè)小組進(jìn)行開(kāi)發(fā)，如果各個(gè)模塊都往develop分支上面丟，那么基本沒(méi)辦法做持續(xù)集成(Continue Integration)的操作。雖然最后集成的時(shí)候各模塊一定會(huì)和諧相處的，但是在開(kāi)發(fā)過(guò)程當(dāng)中，不一定每一個(gè)commit都是向模塊兼容，所以最好能每個(gè)模塊都自行在一個(gè)旮旯搗騰，等最好確定能相親相愛(ài)了，大家再杵到一塊去。

這是我們可以基于模塊創(chuàng)建各種feature分支，有關(guān)開(kāi)發(fā)人員就在相應(yīng)的分支上進(jìn)行開(kāi)發(fā)就行，等到各個(gè)功能分支基本完成了，我們?cè)侔堰@些分支merge到develop上面去

如果有了feature分支，那么develop分支基本就成了集成分支了

release

前面說(shuō)了master分支代表著當(dāng)前產(chǎn)品線上的版本，分分鐘可以上線部署而不會(huì)導(dǎo)致祭天這種結(jié)局的。但這有些項(xiàng)目或團(tuán)隊(duì)有這樣的情況，產(chǎn)品上線前要先部署到準(zhǔn)產(chǎn)品線上去玩，內(nèi)測(cè)一周左右，確定完全沒(méi)有問(wèn)題了再上到產(chǎn)品線上去。在內(nèi)測(cè)的這一周，如果發(fā)現(xiàn)了有問(wèn)題了，趕緊從develop分支進(jìn)行修復(fù)，再上到準(zhǔn)產(chǎn)品線來(lái)驗(yàn)證。如果我們用master分支來(lái)進(jìn)行準(zhǔn)產(chǎn)品線的部署，在內(nèi)測(cè)的這一周發(fā)現(xiàn)問(wèn)題，而這時(shí)我們的產(chǎn)品線上有緊急問(wèn)題要fix，那么我們就無(wú)法直接拿master分支上線，這就做不到我們之前的承諾: master分分鐘可以上線而不用祭天

所以我們可以創(chuàng)建一個(gè)release的分支來(lái)進(jìn)行準(zhǔn)產(chǎn)品線的部署和問(wèn)題修復(fù)，知道確認(rèn)完全沒(méi)有問(wèn)題了，我們?cè)偻降絤aster分支去上線

hotfix

做系統(tǒng)的哪可能沒(méi)有bug！當(dāng)產(chǎn)品線上無(wú)辜出現(xiàn)bug的時(shí)候，我們要去哪個(gè)分支做修復(fù)呢？

• master ：顯然不合適，產(chǎn)品線上由于設(shè)計(jì)或者考慮不周出現(xiàn)bug一般是不用祭天的，但如果因?yàn)檫@樣，在master上面一通亂改，那就有可能要祭天了
• release：這個(gè)是給下一個(gè)版本用的呢。如果是上一個(gè)版本的話，那新增的修改就破壞了原來(lái)版本號(hào)的意義了，比如原來(lái)分支叫release-1.0.1, 那么加了這個(gè)版本還叫這個(gè)名字嗎？
• developer: 如果還有一些其它正在開(kāi)發(fā)的功能，那一會(huì)上線的時(shí)候就會(huì)連帶這個(gè)也稍上去了！
• feature： 這就有點(diǎn)扯遠(yuǎn)了

看來(lái)上面這4種分支都不大合適，那就來(lái)款新的，就叫hotfix. hotfix分支是從master分支直接創(chuàng)建出來(lái)的，用來(lái)做一些產(chǎn)品線上緊急的代碼修復(fù)，或者臨時(shí)添加的小功能。開(kāi)發(fā)人員直接在這個(gè)分支上進(jìn)行開(kāi)發(fā)，功能完成后直接上到master分支再上線。

記得每次hotfix上線后，要把功能同步回developer，再到各feature的分支上