GIT - 代碼分支管理模型之一

就像人心散，隊伍很差帶同樣，代碼版本多，分支也很差管

當產品開發到必定程度後，多版本同時開發，各類熱修復等等問題，勢必會帶來版本分支管理的問題。今天咱們準備一塊兒來看看第一種代碼分支管理方案。

這裏要先強調一下，分支管理的方式各有千秋，不存在誰必定比誰好，只有誰比誰更適合你而已

熱門的成功代碼分支管理

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

這個模型基本能知足企業項目開發過程當中遇到的各類代碼版本管理的需求，下面嘗試着把這種模型分解給你們講講：

咬住青山不放鬆

在上面的圖中，你們能夠看到有兩個分支的名字被加粗了：master 和 develop，這兩個是分支當中的中流砥柱。

#### master

這是新建一個GIT repository以後的第一個分支。在這個模型中，master分支表明的是當前產品線上的版本，它的最後一個commit多是已經上線了，或者已經通過QA/PD/PO 千萬次折磨、分分鐘能夠上線的功能。換句話說，這條分支要作到 隨時均可以上線的！ 要是誰把一個開發了通常的功能提交到這個版本上去，有可能會被PO拉去祭天的！ 因此若是有嚴格的權限管理的話，通常會把這個分支給鎖起來，有且僅有上線的同事纔有權限動它！

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

develop

通常靈長類動物都敬畏祭天這樣的操做，因此咱們須要開闢一篇新天地來大有做爲。爲了和大部隊保持一致，develop的分支是基於master建立出來的

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建立出來的

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

---

文體兩開花

當項目稍微大一些的時候，會遇到各類各樣的版本管理需求，但不必定每一種你都須要，當須要的時候能夠再創建這些分支，好比有 features, release, hotfix

features

第一種狀況比較常見，項目有不少同事並行開發，好比分了多模塊給多個小組進行開發，若是各個模塊都往develop分支上面丟，那麼基本沒辦法作持續集成(Continue Integration)的操做。雖然最後集成的時候各模塊必定會和諧相處的，可是在開發過程中，不必定每個commit都是向模塊兼容，因此最好能每一個模塊都自行在一個旮旯搗騰，等最好肯定能相親相愛了，你們再杵到一塊去。

這是咱們能夠基於模塊建立各類feature分支，有關開發人員就在相應的分支上進行開發就行，等到各個功能分支基本完成了，咱們再把這些分支merge到develop上面去

若是有了feature分支，那麼develop分支基本就成了集成分支了

release

前面說了master分支表明着當前產品線上的版本，分分鐘能夠上線部署而不會致使祭天這種結局的。但這有些項目或團隊有這樣的狀況，產品上線前要先部署到準產品線上去玩，內測一週左右，肯定徹底沒有問題了再上到產品線上去。在內測的這一週，若是發現了有問題了，趕忙從develop分支進行修復，再上到準產品線來驗證。若是咱們用master分支來進行準產品線的部署，在內測的這一週發現問題，而這時咱們的產品線上有緊急問題要fix，那麼咱們就沒法直接拿master分支上線，這就作不到咱們以前的承諾: master分分鐘能夠上線而不用祭天

因此咱們能夠建立一個release的分支來進行準產品線的部署和問題修復，知道確認徹底沒有問題了，咱們再同步到master分支去上線

hotfix

作系統的哪可能沒有bug！當產品線上無辜出現bug的時候，咱們要去哪一個分支作修復呢？

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

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

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

---

以上就是關於 這款 成功的代碼分支管理模型的講解，基本上能知足大部分企業大部分項目的代碼版本管理的需求！ 後面會介紹另一塊代碼分支管理模型，是指咱們公司的一種管理的方式，下回見！