git branch的管理策略網(wǎng)上有不上文章，流傳比較廣泛的應(yīng)該是阮一峰的Git分支管理策略，不過(guò)個(gè)人感覺(jué)這個(gè)策略過(guò)于簡(jiǎn)單筷畦，在實(shí)際的開發(fā)環(huán)節(jié)中，有很多情況不好處理刺洒，這里總結(jié)一些個(gè)人在使用git管理代碼倉(cāng)庫(kù)過(guò)程中的一點(diǎn)想法和思考鳖宾，以及在實(shí)際開發(fā)過(guò)程采用的方法。
分支分類簡(jiǎn)介：
基于常見軟件開發(fā)中場(chǎng)景逆航，將所有分支歸納為三類：
- 正式發(fā)布分支：
- release branch
- release_hotfix_xxxx branch
- 開發(fā)分支：
- develop (主) branch
- develop_xxxx (feature) branch
- 內(nèi)測(cè)發(fā)布分支：
- prepare branch (主) branch
開發(fā)階段簡(jiǎn)介：
- 開發(fā)階段：develop branch & develop_xxxx branch進(jìn)行鼎文。
- 預(yù)發(fā)階段：持續(xù)的merge develop to prepare branch，進(jìn)行內(nèi)測(cè)因俐。
- 線上發(fā)布階段：內(nèi)測(cè)穩(wěn)定“無(wú)問(wèn)題”后拇惋，進(jìn)入線上發(fā)布階段，由發(fā)布o(jì)wner merge prepare branch to release branch女揭。注：線上發(fā)布階段蚤假，prepare branch鎖定不再更新。
正式發(fā)布分支：
release branch
release branch為正式發(fā)布分支吧兔，該branch HEAD保持同當(dāng)前正式發(fā)布最新版本一致磷仰，每一個(gè)正式發(fā)布的版本都在release branch有唯一對(duì)應(yīng)的tag。
- 在進(jìn)入線上發(fā)布之前不允許直接push修改到release branch境蔼，進(jìn)入線上發(fā)布之后僅允許從develop分支上cherry-pick commit灶平。
- merge， cherry-pick操作只由本次發(fā)布o(jì)wner操作箍土，發(fā)布成功打tag逢享。
- 進(jìn)入線上發(fā)布的release branch如果測(cè)試出現(xiàn)重大bug，建議重新進(jìn)入預(yù)發(fā)階段吴藻，如果出現(xiàn)等級(jí)較低的bug瞒爬，盡量在develop修復(fù)，通過(guò)cherry-pick將該筆修復(fù)合入release branch。（如果develop上無(wú)法復(fù)現(xiàn)侧但，必須在release分支上修復(fù)的矢空，允許在release branch修復(fù)，修復(fù)后禀横，將該修改cherry-pick回develop branch）
- 線上發(fā)布階段僅修bug屁药，不加功能，如果需要加功能柏锄，重新進(jìn)入開發(fā)階段酿箭，或者預(yù)發(fā)階段，本次線上發(fā)布操作中止趾娃。
release_hotfix_(version)_(xxxx) branch
hotfix branch為應(yīng)對(duì)突發(fā)情況的發(fā)版缭嫡，基于相應(yīng)正式release branch基礎(chǔ)，checkout一個(gè)hotfix branch進(jìn)行相應(yīng)修復(fù)后茫舶，基于該branch進(jìn)行突發(fā)情況的緊急發(fā)布械巡。
- 該分支只能基于release branch checkout，命名采用release_hotfix_vX.X.X(_feature)
- hotfix branch上新增的修復(fù)commit需同步cherry-pick到develop branch饶氏。
- hotfix branch不允許merge回release branch（參見release branch條目1）
思考：為什么hotfix branch不好merge會(huì)release branch讥耗？
內(nèi)測(cè)發(fā)布分支：
內(nèi)測(cè)發(fā)布分支作為內(nèi)部提測(cè)使用的分支，隔離開發(fā)和內(nèi)測(cè)發(fā)布分支疹启，目的：不影響內(nèi)部提測(cè)和開發(fā)人員的持續(xù)提交古程。
prepare branch
- prepare對(duì)應(yīng)develop的內(nèi)測(cè)分支。
- 任何情況下不允許直接push修改到prepare branch喊崖。
- prepare branch的更新只能通過(guò)develop branch merge更新挣磨。
- 內(nèi)測(cè)發(fā)布分支的merge由內(nèi)測(cè)發(fā)布o(jì)wner操作。
思考：內(nèi)測(cè)發(fā)布分支是否必要荤懂？
開發(fā)分支：
develop branch
develop branch為開發(fā)過(guò)程中的主干分支茁裙，是開發(fā)人員操作最多的分支。
- 小功能节仿，小bug晤锥，獨(dú)立模塊的提交可以直接提交到develop branch。每筆的提交必須保證可build廊宪，可執(zhí)行矾瘾。同時(shí)需盡量保持模塊功能獨(dú)立，完整箭启，版本單一壕翩，不破壞app功能的完整統(tǒng)一，無(wú)大問(wèn)題傅寡。
- develop分支上提交的功能commit必須是本開發(fā)版需要發(fā)布的功能放妈，后續(xù)版本的功能開發(fā)需求北救，采用單獨(dú)拉出develop_feature branch進(jìn)行開發(fā)。
- 提交沖突大猛，需采用rebase合并扭倾，不允許采用merge（git pull默認(rèn)方式）。
rebase和merge的區(qū)別:
略
develop_xxxx branch
大feature的模塊開發(fā)挽绩，會(huì)破壞develop分支功能完整性，非本期開發(fā)需求的開發(fā)工作驾中，需拉出單獨(dú)的develop branch進(jìn)行唉堪。
- branch命名采用develop_xxxx方式，xxxx代表開發(fā)feature肩民。
- develop_xxxx branch只能基于develop branch checkout唠亚。
- develop_xxxx branch開發(fā)完成后通過(guò)git merge --no-ff(非fast-forward)合并回develop branch。
- develop_xxxx branch原則上不允許反向merge develop branch(develop to develop_xxxx)持痰。
--no-ff和fast-forward的區(qū)別：
圖片來(lái)自網(wǎng)絡(luò)灶搜。
為什么不允許反向merge develop branch？
清晰工窍，美觀割卖，好追溯
feature branch一定要merge develop分支才能內(nèi)測(cè)嗎患雏？
- feature branch的測(cè)試關(guān)注于單一模塊功能鹏溯。
- 只有當(dāng)發(fā)現(xiàn)重大bug在develop分支修復(fù)，同時(shí)該bug影響到了feature分支的測(cè)試淹仑，可考慮合并develop分支丙挽。
- 當(dāng)develop分支有基礎(chǔ)庫(kù)的大修改，而當(dāng)前feature分支嚴(yán)重依賴該庫(kù)匀借，如果不進(jìn)行合并颜阐，后續(xù)仍然有很多代碼需要兼容該基礎(chǔ)庫(kù)，導(dǎo)致后續(xù)大部分代碼的編寫無(wú)生產(chǎn)意義時(shí)吓肋，可考慮合并develop分支凳怨。
如果develop_feature branch一定要merge develop分支才能測(cè)試，怎么辦蓬坡？
- 如果該feature由一個(gè)人單獨(dú)開發(fā)猿棉，建議采用git rebase方式合并。（單獨(dú)開發(fā)的功能合并分支盡量采用rebase屑咳，為保證減少合并沖突的難度萨赁，建議在開發(fā)過(guò)程中，以天為單位持續(xù)rebase develop branch）
- 如果該feature由多人開發(fā)兆龙，只能采用git merge進(jìn)行合并杖爽。（盡量在一次merge完成敲董，不要持續(xù)多次merge develop branch）
