GIT代碼分支管理模型的示例分析

這篇文章給大家分享的是有關GIT代碼分支管理模型的示例分析的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

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

A successful Git Branching Model

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

咬住青山不放松

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

master

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

另外master的每次上線都會打一個tag，表明版本號是多少

develop

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

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git branch
* master

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git checkout -b develop
Switched to a new branch 'develop'

C:\githome\github\gitdou (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)建出來的

如果項目不是特別大，版本管理也比較簡單，那么master跟develop這兩個分支就基本夠用了

文體兩開花

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

features

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

這是我們可以基于模塊創(chuàng)建各種feature分支，有關開發(fā)人員就在相應的分支上進行開發(fā)就行，等到各個功能分支基本完成了，我們再把這些分支merge到develop上面去

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

release

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

所以我們可以創(chuàng)建一個release的分支來進行準產(chǎn)品線的部署和問題修復，知道確認完全沒有問題了，我們再同步到master分支去上線

hotfix

做系統(tǒng)的哪可能沒有bug！當產(chǎn)品線上無辜出現(xiàn)bug的時候，我們要去哪個分支做修復呢？

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

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

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

感謝各位的閱讀！關于GIT代碼分支管理模型的示例分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！