工作流簡介

功能驅(qū)動(dòng)開發(fā)

"功能驅(qū)動(dòng)式開發(fā)"（Feature-driven development寺旺，簡稱FDD）.

它指的是，需求是開發(fā)的起點(diǎn)文兢，先有需求再有功能分支（feature branch）或者補(bǔ)丁分支（hotfix branch）。完成開發(fā)后，該分支就合并到主分支，然后被刪除。

如果我們開發(fā)的內(nèi)容在功能的角度上就存在不相容，無法合并缅茉，則這種工作流未必合適。從項(xiàng)目設(shè)計(jì)上講應(yīng)該盡量避免這種情況的出現(xiàn)男摧，否則蔬墩，建議分割項(xiàng)目來解決。

Git flow(Git 工作流)

Git工作流比喻項(xiàng)目像流水一樣順暢自然的向前流動(dòng),不會(huì)發(fā)生沖擊耗拓，對撞拇颅，甚至漩渦。

image.png

目前用的比較廣泛的工作流有三種:

• Git flow
• Github flow
• Gitlab flow

針對目前的項(xiàng)目狀況乔询，本文采用的是最早誕生樟插，并得到廣泛應(yīng)用的Git flow和功能驅(qū)動(dòng)開發(fā)（FDD）以及帶問題追蹤的功能分支管理的GitLab flow結(jié)合。

Git flow

首先，項(xiàng)目存在兩個(gè)長期分支黄锤。

主分支master
開發(fā)分支develop
前者用于存放對外發(fā)布的版本搪缨，任何時(shí)候在這個(gè)分支拿到的，都是穩(wěn)定的分布版鸵熟；后者用于日常開發(fā)副编，存放最新的開發(fā)版。

image.png

其次流强，項(xiàng)目存在三種短期分支痹届。

功能分支（feature branch）
補(bǔ)丁分支（hotfix branch）
預(yù)發(fā)布分支（release branch）
一旦完成開發(fā)，它們就會(huì)被合并進(jìn)develop或master打月，然后被刪除队腐。

GIT Flow總覽

image.png

主分支Master

首先，代碼庫應(yīng)該有一個(gè)僵控、且僅有一個(gè)主分支香到。所有提供給用戶使用的正式版本鱼冀，都在這個(gè)主分支上發(fā)布报破。

對應(yīng)到目前團(tuán)隊(duì)中使用的Gitlab,我們建議使用Master作為主分支并設(shè)置分支保護(hù)（默認(rèn)設(shè)置）,每次發(fā)布打上Tag,如: 0.1, 0.2或0.3

image.png

開發(fā)分支Develop

主分支只用來分布重大版本，日常開發(fā)應(yīng)該在另一條分支上完成千绪。我們把開發(fā)用的分支充易，叫做Develop。

image.png

如果想正式對外發(fā)布荸型，就在Master分支上盹靴，對Develop分支進(jìn)行"合并"（merge）。

由于Gitlab中默認(rèn)對Master設(shè)置了分支保護(hù)(這個(gè)設(shè)置允許取消,如果存在多人開發(fā)的項(xiàng)目,不建議取消),所以,當(dāng)需要合并到Master的時(shí)候需要在Gitlab里提交合并申請,由項(xiàng)目管理員合并.

功能分支Feature

功能分支屬于臨時(shí)性分支,一般合并完就會(huì)刪除.

它是為了開發(fā)某種特定功能瑞妇，從Develop分支上面分出來的稿静。開發(fā)完成后，要再并入Develop辕狰。

功能分支的名字改备，可以采用feature-*的形式命名。

某些情況下,新功能可能需要在線上的版本保持一致,可以從Master里拉出功能分支,也可以.

image.png

實(shí)際應(yīng)用功能分支的時(shí)候,存在以下幾種情況:

1蔓倍、正常迭代,周期性的功能需求
2悬钳、公共模塊更新，所有feature分支都需要同步更新
3偶翅、產(chǎn)品型需求,這種需求的周期很長默勾，需求和項(xiàng)目的主線有很大偏差，同時(shí)要求不跟著主板本迭代

第一種情況聚谁，按照標(biāo)準(zhǔn)的feature分支工作流開展即可,不再贅述母剥。

第二種情況，需要分別關(guān)注兩種情況的處理。
1媳搪、作為公共模塊更新提交者铭段，在本地分支commit后，不在develop分支需要切換到develop分支并pull request秦爆，然后修改公共模塊序愚，最后提交到remote（單次commit的代碼只能包含修改公共模塊的代碼，不能包含UI等限、其他feature分支代碼）爸吮。
2、作為公共模塊拉取者望门，在本地分支commit后形娇，fetch更新remote提交記錄，然后cherry-pick對應(yīng)的commit記錄筹误。

image.png

image.png

產(chǎn)品型需求

這種分支建議以production-分支定義,在功能迭代完成后直接在production-分支上拉出release分支提測,測試完成后,合并回production分支,同時(shí)在production分支上打上tag.

由于這種分支并不合并到主干,所以上線的代碼都體現(xiàn)在production分支上,如果線上有bug需要修復(fù),在tag上拉出fixbug分支修復(fù)即可.

這種分支實(shí)際上相當(dāng)于一個(gè)獨(dú)立的項(xiàng)目進(jìn)行迭代,和本文闡述的分支管理主旨并不相符.

預(yù)發(fā)布分支

它是指發(fā)布正式版本之前（即合并到Master分支之前）桐早，我們可能需要有一個(gè)預(yù)發(fā)布的版本進(jìn)行測試。

預(yù)發(fā)布分支是從Develop分支上面分出來的厨剪，預(yù)發(fā)布結(jié)束以后哄酝，必須合并進(jìn)Develop和Master分支,合并完后刪除分支。

它的命名祷膳，可以采用release-*的形式陶衅。

hotfix分支

軟件正式發(fā)布以后，難免會(huì)出現(xiàn)bug直晨。這時(shí)就需要?jiǎng)?chuàng)建一個(gè)分支搀军，進(jìn)行bug修復(fù)。

hotfix分支是從Master分支上面分出來的勇皇。修補(bǔ)結(jié)束以后罩句，再合并進(jìn)Master和Develop分支。它的命名敛摘，可以采用hotfix-*的形式门烂。

image.png

hotfix分支在提交的時(shí)候,如果存在release分支,需要同時(shí)合并到release分支,避免release分支上線的時(shí)候,合并到master有沖突.

分支命名規(guī)范

受保護(hù)的分支

默認(rèn)情況下，受保護(hù)的分支執(zhí)行以下四個(gè)簡單的操作：

• 它會(huì)阻止除具有“主”權(quán)限的用戶之外的所有用戶創(chuàng)建（如果尚未創(chuàng)建）
• 它可以防止除具有“主”權(quán)限的用戶以外的其他任何人推送
• 它可以防止任何人強(qiáng)制推送分支
• 它阻止任何人刪除分支

版本迭代管理

為了適應(yīng)高速迭代開發(fā)節(jié)奏拖叙，我們會(huì)以一個(gè)月兩個(gè)版本迭代開發(fā)氓润，每個(gè)版本需要安排主程序員和開發(fā)人員，在單次版本開發(fā)中薯鳍，主程序員的職責(zé)是統(tǒng)籌開發(fā)人員咖气，負(fù)責(zé)主要開發(fā)任務(wù)挨措，收集bug并反饋到開發(fā)人員手里，以及feature分支合并申請審核崩溪。而開發(fā)人員只需要完成開發(fā)任務(wù)和bug修復(fù)浅役。下一個(gè)版本主程序員和開發(fā)人員輪換。

擴(kuò)展討論

如何將現(xiàn)有的工作流切換過來伶唯？

若手頭還有工作觉既，需要在你當(dāng)前分支處理的話，可以按照以前的工作流提交你的代碼乳幸，并且提交完代碼后瞪讼，需要每一位開發(fā)者同步一下代碼，之后按照功能驅(qū)動(dòng)式開發(fā)即可粹断。

參考文檔

Git工作流程

A successful Git branching model

Understanding the GitHub flow

GitHub Flow