關(guān)于git flow工作流程的一點思考
具體流程暫不細(xì)表剿配，參考文章中已經(jīng)極為詳細(xì)盛嘿。
Git Flow工作流程
- 開發(fā)階段：從develop分支拉出feature分支進(jìn)行開發(fā)
- 聯(lián)調(diào)階段：直接使用feature分支進(jìn)行聯(lián)調(diào)
- 提測階段：將feature分支合并入develop分支，并基于develop分支拉出release分支進(jìn)行提測
- 發(fā)布階段：將release分支分別合入master分支以及develop分支介返，并打上版本號
碰到的問題
倘若存在2個feature分支[feature1.0/feature.2.0]
feature1.0已經(jīng)合并入develop分支并拉出release分支進(jìn)行提測bug修復(fù)
過了不久，feature2.0開發(fā)完畢，合并入develop分支并拉出release分支進(jìn)行提測
如果第二個分支先于第一個分支發(fā)布冻辩，master就合并進(jìn)了還沒修復(fù)完的feature1.0的代碼
解惑
通過第一文章作者留下的聯(lián)系方式加了他的微信，這是他回復(fù)給我的:
這種工作方式：一般情況要遵循feature1.0分支先于feature2.0發(fā)布拆祈。
也就是：只要先合并到develop就說明已經(jīng)具備先發(fā)的條件恨闪。
同時在第二篇文章阮老師留言下面發(fā)現(xiàn)了同樣類似的回答：
[第二個回答也是我們小團(tuán)隊目前正在使用的方式]
感謝前人。
公司目前使用的流程
- 開發(fā)階段：從master分支拉出feature分支進(jìn)行開發(fā)
- 聯(lián)調(diào)階段：直接使用feature分支進(jìn)行聯(lián)調(diào)
- 提測階段：從master分支拉出一個release分支放坏，使用該release合并feature分支咙咽，然后進(jìn)行提測
- 發(fā)布階段：提測結(jié)束后，將release分支合并入master分支淤年，進(jìn)行發(fā)布钧敞，也可直接發(fā)布release分支再合并入master分支，并打上版本號
好處
需求發(fā)布無需嚴(yán)格遵循需求先后發(fā)布時間麸粮，不存在標(biāo)準(zhǔn)git flow工作流程碰到的問題
缺陷
在標(biāo)準(zhǔn)工作流中
master分支用來記錄官方發(fā)布軌跡溉苛；develop分支是一個集成分支，用來記錄開發(fā)新功能的軌跡弄诲。
而在實際開發(fā)過程中由于沒有使用develop分支愚战，master分支commit較為混亂，使用標(biāo)準(zhǔn)工作流又會碰到發(fā)布沖突的問題
- 總結(jié)
來自第一篇文章作者(再次表達(dá)感謝)：
不管用什么方式，能保證工作順利進(jìn)行就行寂玲。
每個項目工程的復(fù)雜度都不一樣塔插，要從實踐中找到適合團(tuán)隊協(xié)作的方式。
還就是敢茁，有些約定佑淀，是必須遵循的。
后話
最近寫博客越發(fā)覺得自己只是知識的復(fù)述者彰檬，復(fù)述得還沒有別人好伸刃，開始懷疑自己花時間投入寫博客是否值得。
自己還處于學(xué)習(xí)階段逢倍，也沒有原創(chuàng)輸出捧颅。
倘若不寫，又感覺自己學(xué)習(xí)的知識印象不深较雕，寫還是要寫的碉哑，權(quán)當(dāng)學(xué)習(xí)記錄了。
當(dāng)然亮蒋，倘若能夠幫助到一些人扣典，我會更開心。
如果文中有表述不當(dāng)?shù)牡胤竭€望指出慎玖≈猓互相學(xué)習(xí)共同進(jìn)步。
