通俗的說，任何分支策略都可以在一個團隊中執(zhí)行下去汰现，無非使起來好用或不好用挂谍。什么好的策略呢？我認為瞎饲，好的策略有以下幾個特點：
- 保證代碼安全口叙；
- 版本管理有序；
-
程序員無感知嗅战；
前兩點往往是我們所追求的核心目標妄田，通過分支管理，將生產(chǎn)代碼和開發(fā)代碼甚至測試階段的代碼區(qū)別開，保證各個環(huán)境的應(yīng)用獨立疟呐。至于程序員無感知脚曾，只能說是一個美好的愿望，意思是分支管理清晰萨醒，操作簡潔斟珊。其實一個團隊的分支策略會隨著團隊業(yè)務(wù)苇倡、規(guī)模而變化富纸，這里介紹幾種分支策略，讀者可根據(jù)實際情況運用旨椒。
主干分支策略
所謂主干分支策略晓褪，指的是所有開發(fā)人員共享同一個trunk進行開發(fā)，當需要發(fā)布的時候综慎，可以基于現(xiàn)有的trunk拉出一個新的release分支涣仿，進行測試和發(fā)布。當然這里會有一個問題示惊，共享分支開發(fā)的前提下好港，拉取分支可能導(dǎo)致無需上線的代碼被拉到release分支，所以這個時候米罚，可能需要通過cherry-pick從主干上挑取需要上線的commit钧汹。
這樣做的優(yōu)點很明顯，分支結(jié)構(gòu)簡潔录择，但是一旦要上線的時候拔莱，就需要相關(guān)的開發(fā)人員更加仔細，避免多余代碼帶上生產(chǎn)環(huán)境隘竭。這里多說一句塘秦，網(wǎng)上其他文章有提到“主干分支策略會減少沖突的發(fā)生”，我認為可以這么說动看，解釋一下尊剔，這里我也拉出一個分支說說沖突發(fā)生的原因：不同的提交對同一文件的同一部分（我理解為同一行）進行了不同的修改，則會產(chǎn)生沖突菱皆。如果同一文件的不同部分修改了赋兵，或者同一文件同一部分修改的內(nèi)容一樣，也不會產(chǎn)生沖突搔预。
git flow（最常見的分支策略）
網(wǎng)絡(luò)上有文章介紹了常見的git flow／github flow／gitlab flow等分支策略束莫，其中g(shù)ithub flow多適用于組織性不強的開源項目開發(fā)。git flow和gitlab flow可以整在一起講講草描。其實這種git flow方式應(yīng)該是市面上最具共識的開發(fā)方式览绿，扒一張優(yōu)秀的圖：
朋友先別慌，這圖很好理解穗慕，最上面分了5個分支饿敲，其中兩粗三細，意味著develop和master是兩個常備分支揍诽，而feature branch诀蓉，release branch和hotfixes是協(xié)助分支，也就是說暑脆，粗的是一直都在的渠啤，而且不會變來變?nèi)ィ毜目赡芤驗閳鼍疤砺稹㈤_發(fā)人數(shù)沥曹、線上bug數(shù)而增多或減少。
開發(fā)人員的feature branch來自于develop branch碟联，每當develop branch達到某個穩(wěn)定時期妓美，或者團隊的迭代周期一到，develop上的代碼會發(fā)布到release branch進行測試鲤孵，一旦測出有問題壶栋，可以直接在release branch做bug fix，當然規(guī)范起見普监，也可以在相應(yīng)的feature branch上修改了贵试，一層層傳遞到release branch琉兜。當一切測試通過，release branch發(fā)布到master毙玻。
當然這個過程中會有一些變通豌蟋，我們可以把develop和release branch都看做測試分支，也就是說桑滩，當我們開發(fā)完梧疲，會經(jīng)歷兩個環(huán)境的測試，然后上線运准。這樣一說是不是跟實際聯(lián)系的更緊了幌氮。無論怎么變換，這種方式的特點在于：
- feature branch由developer產(chǎn)生戳吝，保證了開發(fā)人員的基礎(chǔ)版本是當前最新的版本（developer上的代碼往往是已經(jīng)提測的代碼）浩销，最大程度的避免沖突贯涎，上文已解釋听哭。
-
代碼在分支之間一層層的merge，直到發(fā)布塘雳，這要做的好處是通過機制陆盘，減少了誤操作，我們當然會對線上安全格外看中败明，release branch測試通過的代碼merge到master隘马，操作簡便，不易出錯妻顶。
是不是怎么看怎么好酸员？git flow的弊端也正是由這兩個特點產(chǎn)生的。對于團隊迭代嚴格掌握讳嘱，各個項目節(jié)點嚴格遵守的團隊幔嗦，這樣的策略是沒有問題的，但是現(xiàn)實當中也不免有很多小快靈的團隊沥潭。
git拉取代碼這個圖表達的意思是小王和小李都從develop分支拉取代碼邀泉，小王先拉，也先提交钝鸽；小李在小王提交后拉取汇恤，開發(fā)完成之后，小李也提交到develop拔恰。這時候測試人員宣布因谎，小李的可以上線，小王的得等等颜懊〔撇恚可這時候阱穗，小李的提交可以直接merge到release分支么？不行使鹅！小李的提交中帶有小王還未通過測試的提交揪阶。粗暴的上線不可以，只有cherry-pick患朱，可怕的是鲁僚，如果小李用到了小王的部分代碼，單純的cherry-pick可能還不能解決問題裁厅。所以從develop上拉取feature branch和層層merge對于小快靈或者嚴格迭代制度的團隊不一定適用冰沙。
基于feature branch的策略
其實也就是針對上述策略的不足之處，進行針對性的改良执虹，分支結(jié)構(gòu)沒什么變化拓挥，特別之處兩點：
- feature branch來自于master而非develop，這樣一來袋励，都是基于當前的生產(chǎn)版本進行的開發(fā)侥啤，并行開發(fā)的分支互補影響上線；
- 所有發(fā)布分支（develop, release, master）的部署都和feature branch進行合并茬故，而非層層遞進合并盖灸；這樣做的好處在于，代碼發(fā)布指哪打哪磺芭，不會混帶著無關(guān)代碼赁炎。
當然，這樣做也有相應(yīng)的弊端钾腺，代碼沖突出現(xiàn)的機率比git flow要大徙垫，另外由于分支不是層層遞進的發(fā)布，相當于人的權(quán)利更大（因為都是合各自的feature branch）放棒，發(fā)布安全需要人員的素質(zhì)和自覺姻报。
以上三種分支策略已經(jīng)介紹完畢，還是那句話哨查，沒有分支策略適用于所有項目或者一個項目的所有階段逗抑。所以我建議的分支策略是：酌情考慮，不行就換寒亥。
