當前大部分團隊都使用git flow流程管理代碼(不了解gitflow的朋友可以自行搜索)秧耗，以我們團隊的狀況來看，一個產(chǎn)品的開發(fā)初期是比較適合用git flow的舶治，因為初期都是在做功能添加分井，而且人比較少，每個迭代只更新一個或幾個完整的功能歼疮。到了后期的功能調整階段杂抽，git flow就不太適用了，人員多了就可以做更多的事韩脏，可能有多個模塊需要調整，多個版本同時在開發(fā)铸磅。
我們的前端組遇到過這樣的情況赡矢，在同一個倉庫中，三個人同時進行開發(fā)阅仔，做不同的功能吹散，一個人配合客戶端修改JSBridge，一個人給運營做活動頁面八酒，還有一個人在開發(fā)新功能空民。其中配合客戶端的修改要和客戶端一起上線，活動頁面要按運營的時間表上線羞迷，新功能要等服務端部署上線界轩，這就有三個上線時間點。按照gitflow的流程管理衔瓮，開發(fā)完畢的feature都合并到develop浊猾，發(fā)布的時候我們遇到了困難，客戶端準備上線了热鞍，需要將此倉庫發(fā)布葫慎，但是活動頁面還沒到活動的日期衔彻，不能讓用戶提前看到。為了解決這個問題偷办，我們只好在幾個修改的地方都加上了版本號判斷艰额，類似的問題也在服務端和客戶端的發(fā)布中出現(xiàn)過。
為了規(guī)避這種問題椒涯，我們制定了一種新的代碼管理流程悴晰，我們稱之為feature flow
主要分支
- master
- develop
master分支用于發(fā)布版本，在發(fā)布之前將已經(jīng)測試完畢的feature和bugfix合并到master分支逐工，不允許從develop分支直接合并到master
develop分支是眾多feature和bugfix的合集铡溪，代碼雜亂不可直接合并到master分支，而且不允許在develop分支上commit代碼
feature
代碼管理以feature為核心泪喊，例如開發(fā)一個feature A棕硫，則從master拉一個分支featureA出來，在featureA上開發(fā)完成后合并到develop分支袒啼，發(fā)測試包測試哈扮，如有問題則繼續(xù)在featureA上修復，然后合并develop分支再發(fā)包測試蚓再，測試完畢后featureA放在那里等待發(fā)布滑肉。
當決定發(fā)布一個新版本時，會挑選多個feature摘仅，這些feature分支都是開發(fā)并測試完畢的靶庙，將它們合并到master之后刪除，在master上發(fā)布娃属。
這樣做的原因是現(xiàn)在一般都是多個版本的開發(fā)同時進行六荒，不能確定某個版本發(fā)布時會包含哪些feature，若像之前一樣git flow管理的話矾端，合并到develop的feature想摘出來會十分困難
bugfix
bug修復分兩種情況進行管理
- 簡單bug掏击，指修復后容易測試，可確認修復不會造成其它問題
- 復雜bug秩铆，修復后不容易測試砚亭，有隱患帶來其它問題，需長時間測試或認真考慮在哪個版本發(fā)布的問題
簡單bug修復不必遵循feature管理的原則殴玛，在develop分支測試完成后直接合并到master分支
復雜bug修復和feature管理做相同處理
feature分支過多
如果feature本身小而數(shù)量多捅膘，可以將確定會一起發(fā)布的feature合并到一個存儲分支，比如一個版本號分支2.0.6
