良好的分支管理有利于整個項目的穩(wěn)步迭代與團隊成員間的密切合作入宦，故而本文將介紹一個成熟的git分支管理模型摇天，用作實踐參考。
主分支
中心倉庫持有兩條生命期為無限的分支：
1.主分支（master）
2.開發(fā)分支（develop）
master 分支
我們將 origin/master 作為一條主分支补君，其頭指針 HEAD 總是指向一個生產(chǎn)就緒的狀態(tài)润樱。所以，每一次有修改部分被合并到 master 分支時爸舒，就意味著一個新的產(chǎn)品已經(jīng)被發(fā)行出來蟋字，即我們的git腳本將會自動構(gòu)建或回滾我們的軟件，并將其部署到生產(chǎn)服務(wù)器中扭勉。
develop 分支
我們把 origin/develop 作為另一條主分支鹊奖，其頭指針 HEAD 總是指向最新一次提交的開發(fā)更新版本，該更新版本用于下一個版本的發(fā)行涂炎。這也就是說忠聚，當 develop 分支上的代碼達到了一個相對穩(wěn)定的设哗、能發(fā)行的時候，所有在 develop 分支上的代碼都應(yīng)該被合并到 master 分支上去两蟀，并用一個新的發(fā)行號來標記它网梢。
支承分支
在主分支下，本模型使用了三種不同的支承分支來幫助解決團隊成員之間的平行開發(fā)赂毯、發(fā)行準備及現(xiàn)場部署所帶來的問題战虏。不同于主分支，這些支承分支的生命周期是有限的党涕，最終肯定會被移除烦感。
支承分支包括：
1.特征分支（Feature branches）
2.發(fā)行分支（Release branches）
3.熱補丁分支（Hotfix branches）
Feature 分支
Feature 分支從 develop 分支分離出來，最終會合并到 develop 分支中去膛堤。
有時手趣，我們開發(fā)新功能的時候，并不知道該新功能將會在未來的哪個版本發(fā)行肥荔，甚至會被丟棄绿渣。這時就可以使用 Feature 分支，當該新功能開發(fā)完成時燕耿，F(xiàn)eature 分支會被合并到 develop 分支中符，或者直接被丟棄。
Release 分支
Release 分支從 develop 分支分離出來缸棵，最終會合并到 master/develop 分支中去舟茶。
Release 分支用于為新產(chǎn)品的發(fā)行作準備，如漏洞修補堵第，準備元數(shù)據(jù)等吧凉。若當前版本為1.1.5的產(chǎn)品有一個大的版本1.2（而不是1.1.6或者2.0）即將推出，踏志，那么我們就會從 develop 分支分離一條 Release 分支阀捅，當該 Release 分支到達能真正發(fā)行的狀態(tài)時，就可以將其合并到 master 分支上针余，同時饲鄙，為保證以后的發(fā)行不會遺漏這些小漏洞的修復，還需將其合并回 develop 分支圆雁。
注意忍级，嚴格禁止在 release 分支上添加新的大功能。
Hotfix 分支
Hotfix 分支從 master 分支分離出來伪朽，最終會合并到 master/develop 分支中去轴咱。
若當前產(chǎn)品有一個漏洞必須得就快修復，那么我們可以從 master 分支上分離出一條 hotfix 分支，如此一來朴肺，當團隊中有一個成員去修復產(chǎn)品漏洞時窖剑，其他工作于 develop 分支的團隊成員就可以繼續(xù)工作，而不相互產(chǎn)生影響了戈稿。
特別的西土，當同時有一個 release 分支存在時，因為release 分支最終也會合并到 develop 分支鞍盗，所以 hotfix 分支應(yīng)該合并到該 release分支需了，而不是 develop 分支。
