用了 Git 多年霎苗，優(yōu)勢和挑戰(zhàn)都是深有體會唁盏。
話不多說，直接上問題：如何在足夠規(guī)模團(tuán)隊中高效使用 Git 管理代碼昆淡？
繼續(xù)不多話昂灵，直接上答案：分支管理恕曲。
Git 的分支管理有很多實(shí)踐佩谣，有些是從 SVN 類的集中式版本管理工具繼承的，有些是根據(jù) Git 自己的特性總結(jié)的调鬓，目前市面上比較有名的三種 Git 分支管理模型是：
- TrunkBased：主干在手腾窝，天下我有虹脯。所有代碼都往主干上招呼循集，發(fā)版也只用主干咒彤。
- GitFlow：嚴(yán)謹(jǐn)镶柱、規(guī)范、難用，主要是記不住該往哪個分支合并了。
- AoneFlow：前兩種都不行逻卖，那就借鑒各自的優(yōu)點(diǎn)评也，達(dá)到陰陽平衡盗迟，中庸也罚缕。
TrunkBased
TrunkBased怎静，又叫主干開發(fā)蚓聘，有一個網(wǎng)站專門介紹這種開發(fā)方式：Trunk Based Development夜牡。
TrunkBased 是持續(xù)集成思想所崇尚的工作方式塘装，它由單個主干分支和許多發(fā)布分支組成，每個發(fā)布分支在特定版本的提交點(diǎn)上從主干創(chuàng)建出來袋毙，用來進(jìn)行上線部署和 Hotfix听盖。在 TrunkBased 模式中皆看，沒有顯性的特性分支背零。當(dāng)然實(shí)際上 Git 的分布式特征天生允許每個人有本地分支，TrunkBased 也并非排斥短期的特性分支存在嫉称，只不過在說這種模式的時候灵疮，大家通常都不會明確強(qiáng)調(diào)它罷了震捣。
使用主干開發(fā)后蒿赢，我們的代碼庫原則上就只能有一個 Trunk 分支即 master 分支了，所有新功能的提交也都提交到 master 分支上壹若，保證每次提交后 master 分支都是可隨時發(fā)布的狀態(tài)舌稀。沒有了分支的代碼隔離灼擂，測試和解決沖突都變得簡單剔应，持續(xù)集成也變得穩(wěn)定了許多。
但是這種方案缺點(diǎn)也比較明顯席怪，如果大家都在主干進(jìn)行開發(fā)挂捻，當(dāng)代碼提交合并時刻撒，將會異常痛苦耿导，一不小心就會出現(xiàn)沖突舱呻。而且，這種因?yàn)檫@種方式?jīng)]有明顯的特性分支柿冲，想要移除已經(jīng)上線的特性會變得非常困難兆旬。（如果你說把不要的功能注釋，重新發(fā)版慨亲，那就當(dāng)我什么也沒說。）還有一種方案是引入特性開關(guān)巴刻，通過開關(guān)控制特性是否啟用和關(guān)閉，但是增加開關(guān)就引入了復(fù)雜性沥寥，引入復(fù)雜性就引入了出 bug 的風(fēng)險邑雅，畢竟多增加的每行代碼都有可能是一個新的 bug淮野。
GitFlow
GitFlow 來源于 Vincent Driessen 提出的 A successful Git branching model骤星，整體來說洞难，是一套完善的版本管理流程揭朝。缺點(diǎn)就是太過嚴(yán)格，不太適合喜歡自由而且懶的程序猿露筒。當(dāng)然慎式，在程序猿這種物種中，沒有完美的解決方案癣防，總有那么一小撮人會覺得不好蕾盯。參考 Ant蓝丙、Maven 和 Gradle渺尘。
先上圖：
GitFlow 常用分支：
- 主干分支（
master）：最近發(fā)布到生產(chǎn)環(huán)境代碼的分支鸥跟，這個分支只能從其他分支合并医咨，不能再 Master 分支直接修改干茉。 - 主開發(fā)分支（
develop）：包含所有要發(fā)布到下一個 Release 版本的代碼很泊〕虐觯可以在 Develop 直接開發(fā)争涌，也可以將 Feature 的特性代碼合并到 Develop 中。
主開發(fā)分支 - 特性分支（
feature/*）：功能項(xiàng)開發(fā)分支，以feature/開頭命名分支饮潦，當(dāng)功能項(xiàng)開發(fā)完成回俐，將被合并到主開發(fā)分支進(jìn)入下一個 Release，合并完分支后一般會刪點(diǎn)這個特性分支仅颇。
特性分支 - 發(fā)布分支（
release/*）：基于主開發(fā)分支創(chuàng)建的一個發(fā)布分支搁廓，以release/開頭命名分支境蜕，用于測試粱年、bug 修復(fù)及上線。完成后逼泣，合并到主干分支和主開發(fā)分支，同時在主干分支上打個 Tag 記住 Release 版本號秃励，然后可以刪除發(fā)布分支唤衫。
發(fā)布分支 - 熱修復(fù)分支（
hotfix/*）：用于解決線上 Release 版本出現(xiàn)的 bug扣泊，以hotfix/開頭命名分支澎现，修復(fù)線上問題干旧，完成后，合并到主干分支和主開發(fā)分支捐名，同時在主干分支上打個 tag。
熱修復(fù)分支
根據(jù)上面描述断箫，GitFlow 是一套完整的從開發(fā)到生產(chǎn)的管理方式婶熬，但是各種分支來回切換及合并埃撵，很容易把人搞暈赵颅，所以用的人也是越來越少。
AoneFlow
AoneFlow 是阿里內(nèi)部的一套版本管理模型暂刘，兼顧了 TrunkBased 易于持續(xù)集成和 GitFlow 易于管理需求的特點(diǎn)饺谬，又規(guī)避了 GitFlow 分支繁瑣的缺點(diǎn)，也就是中庸谣拣。
AoneFlow 使用三個分支：主干分支（master）贵涵、特性分支（feature/*）决采、發(fā)布分支（release/*），以及三條原則：
規(guī)則一爷抓，開始工作前，從主干分支創(chuàng)建特性分支群嗤。
這條規(guī)則借鑒了 GitFlow清女，每當(dāng)開始一件新的工作項(xiàng)（比如新的功能或是待解決的問題，可以是一個人完成，或是多個人協(xié)作完成）時楞卡，從代表最新已發(fā)布版本的主干分支上創(chuàng)建一個通常以feature/前綴命名的特性分支险绘，然后在這個分支上提交代碼修改。也就是說，每個工作項(xiàng)對應(yīng)一個特性分支光绕，所有的修改都不允許直接提交到主干。
特性分支不止承擔(dān)了新功能拴孤，也是待解決問題的分支化漆。對于我們團(tuán)隊贞谓，為了避免歧義赃梧，會將新功能以feature/為前綴锻拘，待解決問題以hotfix/為前綴骗露，除了名稱外，其他都按照規(guī)則一執(zhí)行。
規(guī)則二还蹲，通過合并特性分支，形成發(fā)布分支。
GitFlow 先將已經(jīng)完成的特性分支合并回主干分支和主開發(fā)分支霜瘪，然后在主干分支上打 Tag 記錄發(fā)布信息鳖枕。TrunkBased 是等所有需要的特性都在主干分支上開發(fā)完成罚舱，然后從主干分支的特定位置拉出發(fā)布分支。而 AoneFlow 的思路是蚌卤，從主干上拉出一條新分支，將所有本次要集成或發(fā)布的特性分支依次合并過去悟狱，從而得到發(fā)布分支，發(fā)布分支通常以release/前綴命名向抢。
我們可以將每條發(fā)布分支與具體的環(huán)境相對應(yīng)，release/test對應(yīng)部署測試環(huán)境针姿，release/prod對應(yīng)線上正式環(huán)境等袱吆，并與流水線工具相結(jié)合，串聯(lián)各個環(huán)境上的代碼質(zhì)量掃描和自動化測試關(guān)卡距淫，將產(chǎn)出的部署包直接發(fā)布到相應(yīng)環(huán)境上绞绒。
另外，發(fā)布分支的特性組成是動態(tài)的榕暇，調(diào)整起來特別容易蓬衡。在一些市場瞬息萬變的互聯(lián)網(wǎng)企業(yè)喻杈，以及采用“敏捷運(yùn)作”的乙方企業(yè)經(jīng)常會遇到這種情況，已經(jīng)完成就等待上線的需求狰晚，隨時可能由于市場策略調(diào)整或者甲方的一個臨時決定筒饰，其中某個功能忽然要求延遲發(fā)布或者干脆不要了。再或者是某個特性在上線前發(fā)現(xiàn)存在嚴(yán)重的開發(fā)問題壁晒，需要排除瓷们。按往常的做法，這時候就要來手工“剔代碼”了秒咐，將已經(jīng)合并到開發(fā)分支或者主干分支的相關(guān)提交一個個剔除出去谬晕，做過的同學(xué)都知道很麻煩。在 AoneFlow 模式下携取，重建發(fā)布分支攒钳，只需要將原本的發(fā)布分支刪掉，從主干拉出新的同名發(fā)布分支雷滋，再把需要保留的各特性分支合并過來就搞定不撑，而且代碼是干凈的，沒有包含不必要的特性晤斩。
此外焕檬，發(fā)布分支之間是松耦合的，這樣就可以有多個集成環(huán)境分別進(jìn)行不同的特性組合的集成測試尸昧，也能方便的管理各個特性進(jìn)入到不同環(huán)境上部署的時機(jī)揩页。松耦合并不代表沒有相關(guān)性，由于測試環(huán)境烹俗、集成環(huán)境爆侣、預(yù)發(fā)布環(huán)境、灰度環(huán)境和線上正式環(huán)境等發(fā)布流程通常是順序進(jìn)行的幢妄，在流程上可以要求只有通過前一環(huán)境驗(yàn)證的特性兔仰，才能傳遞到下一個環(huán)境做部署，形成漏斗形的特性發(fā)布流蕉鸳。當(dāng)然乎赴，這種玩法比較適合有完整開發(fā)集成平臺的公司，小團(tuán)隊玩不轉(zhuǎn)潮尝，比如我們團(tuán)隊就玩不動這種高級玩法榕吼。
規(guī)則三，發(fā)布到線上正式環(huán)境后勉失，合并相應(yīng)的發(fā)布分支到主干羹蚣，在主干添加 Tag，同時刪除該發(fā)布分支關(guān)聯(lián)的特性分支乱凿。
當(dāng)一條發(fā)布分支上的流水線完成了一次線上正式環(huán)境的部署顽素，就意味著相應(yīng)的功能真正的發(fā)布了咽弦，此時應(yīng)該將這條發(fā)布分支合并到主干。為了避免在代碼倉庫里堆積大量歷史上的特性分支胁出，還應(yīng)該清理掉已經(jīng)上線部分特性分支型型。與 GitFlow 相似，主干分支上的最新版本始終與線上版本一致全蝶，如果要回溯歷史版本闹蒜，只需在主干分支上找到相應(yīng)的版本標(biāo)簽即可。
除了基本規(guī)則，還有一些實(shí)際操作中不成文的技巧丈冬。比如上線后的熱修復(fù)，正常的處理方法應(yīng)該是甘畅，創(chuàng)建一條新的發(fā)布分支埂蕊，對應(yīng)線上環(huán)境（相當(dāng)于 Hotfix 分支），同時為這個分支創(chuàng)建臨時流水線疏唾，以保障必要的發(fā)布前檢查和冒煙測試能夠自動執(zhí)行蓄氧。
再啰嗦幾句廢話
不管哪種方式，既然存在槐脏，都會有一定合理性喉童。所以，不管最終翻了哪個牌子顿天，不是因?yàn)檫@個好看堂氯，而是因?yàn)檫@個更適合自己。
個人主頁：https://www.howardliu.cn
個人博文：如何在足夠規(guī)模團(tuán)隊中高效使用 Git 管理代碼牌废？
CSDN 主頁：http://blog.csdn.net/liuxinghao
CSDN 博文：如何在足夠規(guī)模團(tuán)隊中高效使用 Git 管理代碼咽白？
