轉載

GIT工作流簡介

功能驅動開發(fā)

"功能驅動式開發(fā)"（Feature-driven development查近，簡稱FDD）.

它指的是系瓢，需求是開發(fā)的起點蟹地，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）逮走。完成開發(fā)后乎婿，該分支就合并到主分支，然后被刪除票唆。

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

Git flow(Git 工作流)

Git工作流比喻項目像流水一樣順暢自然的向前流動,不會發(fā)生沖擊,對撞,甚至漩渦.

image.png

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

• Git flow
• Github flow
• Gitlab flow

針對目前的項目狀況朴读，本文采用的是最早誕生，并得到廣泛應用的Git flow走趋。

Git flow

首先衅金，項目存在兩個長期分支。

主分支master
開發(fā)分支develop
前者用于存放對外發(fā)布的版本簿煌，任何時候在這個分支拿到的氮唯，都是穩(wěn)定的分布版；后者用于日常開發(fā)姨伟，存放最新的開發(fā)版惩琉。

image.png

其次，項目存在三種短期分支夺荒。

功能分支（feature branch）
補丁分支（hotfix branch）
預發(fā)分支（release branch）
一旦完成開發(fā)瞒渠，它們就會被合并進develop或master，然后被刪除技扼。

GIT Flow總覽

image.png

主分支Master

首先伍玖，代碼庫應該有一個、且僅有一個主分支剿吻。所有提供給用戶使用的正式版本私沮，都在這個主分支上發(fā)布。

對應到目前團隊中使用的Gitlab,我們建議使用Master作為主分支并設置分支保護（默認設置）,每次發(fā)布打上Tag,如: 0.1, 0.2或0.3

image.png

開發(fā)分支Develop

主分支只用來分布重大版本和橙，日常開發(fā)應該在另一條分支上完成仔燕。我們把開發(fā)用的分支，叫做Develop魔招。

image.png

如果想正式對外發(fā)布晰搀，就在Master分支上，對Develop分支進行"合并"（merge）办斑。

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

功能分支

功能分支屬于臨時性分支,一般合并完就會刪除.

它是為了開發(fā)某種特定功能外恕，從Develop分支上面分出來的杆逗。開發(fā)完成后，要再并入Develop鳞疲。

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

比如我們正在開發(fā)分支中開發(fā)小宇睿聯(lián)的需求,這個過程中來了5M微循環(huán)的遷移任務,這個時候,就可以從Develop分支中拉出一個5M的功能分支進行開發(fā),避免兩個需求開發(fā)重疊.

可能大家還會有疑問,開發(fā)分支里已經(jīng)有一部分小宇睿聯(lián)的內(nèi)容,拉出來分支會不會有影響,這種情況可以評估下,如果存在沖突的話可以從Develop分支中向上回溯到一個合適的Commit拉出功能分支來.

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

image.png

實際應用功能分支的時候,存在以下幾種情況:

1. 正常迭代,周期性的功能需求
2. 產(chǎn)品型需求,這種需求的周期很長,需求和項目的主線有很大偏差,同時要求不跟著主板本迭代,如: 本地化部署

第一種情況,按照標準的feature分支工作流開展即可,不再贅述.

產(chǎn)品型需求

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

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

這種分支實際上相當于一個獨立的項目進行迭代,和本文闡述的分支管理主旨并不相符.

[圖片來不及畫]

預發(fā)布分支

它是指發(fā)布正式版本之前（即合并到Master分支之前）尚洽，我們可能需要有一個預發(fā)布的版本進行測試悔橄。

預發(fā)布分支是從Develop分支上面分出來的，預發(fā)布結束以后腺毫，必須合并進Develop和Master分支,合并完后刪除分支癣疟。

它的命名，可以采用release-*的形式潮酒。

比如我們小宇睿聯(lián)的需求已經(jīng)開發(fā)完成了需要提測,這個時候我們可以從Develop中拉去一個預發(fā)布分支,提交測試.測試過程中出現(xiàn)了bug,就在這個分支里修復,當小宇睿聯(lián)上線后,把分支合并回Develop,同時合并到Master分支,并在Master分支上打上Tag.

修補bug分支

軟件正式發(fā)布以后睛挚，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支急黎，進行bug修補扎狱。

修補bug分支是從Master分支上面分出來的。修補結束以后勃教，再合并進Master和Develop分支淤击。它的命名，可以采用fixbug-*的形式荣回。

image.png

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

Git合并的命令推薦

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;"> git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
git push origin develop</pre>

|

默認情況下，Git執(zhí)行"快進式合并"（fast-farward merge）戈咳，會直接將myfeature分支指向Develop分支心软。使用--no-ff參數(shù)后，會執(zhí)行正常合并著蛙，在Master分支上生成一個新節(jié)點删铃。為了保證版本演進的清晰，我們希望采用這種做法踏堡。

image.png

分支命名規(guī)范

<colgroup><col><col><col></colgroup>
| 分支類型 | 命名 | 說明 |
| 主干 | master |
|
| 開發(fā)分支 | develop |
|
| 功能分支 | feature-* | 使用禪道的需求編號(如果對應的需求編號過多,也可以使用拼音縮寫) |
| 預發(fā)布分支 | release-* | 使用日期+版本號 , 如: 20181016-1.2 |
| bug分支 | fixbug-* hotfix-* | 使用禪道的bug工單號,或者根據(jù)當前tag版本號增加 |
| 產(chǎn)品分支 | production-* | 產(chǎn)品分支,對于獨立進化的分支,如本地化部署 |

新平臺開發(fā)場景指引

目前新平臺開發(fā)場景大概有以下幾種情形:

1. 普通迭代
2. 線上bug修復
3. 功能提測
4. 新的項目功能加入

針對這幾種情形,我們依次給出指引

普通迭代

日常的迭代我們一般推薦在Develop下正常開發(fā)即可,提測的時候拉出Release-xxx分支提交測試,測試完了,如果需要上生產(chǎn)則分別合并到Develop和Master,同時在Master上打上Tag(Tag-x.x.x)標記,刪除Release分支.如果,暫時不上生產(chǎn)則合并回Develop,暫時保留Release分支,等待發(fā)布到生產(chǎn).

比如我們現(xiàn)在正在開發(fā)新能源遷移,這個時候并沒有新的功能加入,我們只需要按照普通迭代開發(fā)即可.

線上bug修復

在Master分支里拉出bug-xxx分支修復bug,修復完成后提交測試,測試通過,分別合并到Develop和Master,再刪除bug分支.

功能提測

提測的時候拉出Release-xxx分支提交測試,測試完了,如果需要上生產(chǎn)則分別合并到Develop和Master,同時在Master上打上Tag(Tag-x.x.x)標記,刪除Release分支

新的項目功能加入

普通迭代過程中收到了新的需求開發(fā),為了不造成影響,在Develop分支里拉出Feature分支開發(fā)功能需求,開發(fā)完成后,合并到Develop.提測的時候,在Develop中拉出Release-xxx分支提交測試,測試完畢參照功能提測.

常見問題

5M微循環(huán)作為一個獨立分支,是面對客戶獨立部署,將來可能不希望跟著正常迭代走,在分支上該如何管理?

這種情況,由于存在兩個線上環(huán)境,實際上等于存在兩個Master分支,其中一個是5M的分支,它最終也會作為一個長期分支存在,后續(xù)的功能開發(fā),或者Bug修復都在這個分支上拉出功能分支來進行,完成測試后再合并回5M的分支,這個工作流有點像Github flow(詳見參考文檔).

正常迭代過程中修復了一個bug可能涉及到其他功能分支,如何處理?

保險起見,最好在不同的分支里分別提交,這樣做不可避免的會帶來一些麻煩,所以,我們在項目的迭代周期上,一定不要太長,否則遺留的功能/測試分支太多,會給開發(fā)人員的開發(fā)帶來麻煩.

新的功能開發(fā)完成提交了Release分支,如何保證舊的功能不會收新功能影響?

這個問題本質上并不是工作流的問題,這里也拿出來講一下,解決這個問題,還是需要從測試著手,而測試分為兩塊,白盒測試和黑盒測試.對于開發(fā)人員,項目中開發(fā)的功能都需要有單元測試能夠覆蓋到,當新的功能開發(fā)完成后,完整的執(zhí)行一遍單元測試,可以檢查對舊功能是否造成影響.同樣測試人員也會針對上線功能進行完成測試.

新能源遷移的功能分支,由于短期內(nèi)無法上線,這些分支在測試完后,如何處理?

這些分支在功能開發(fā)完成后,就合并到了Develop分支了,提測生成的測試分支,由于暫時無法上線,暫時不要合并到主干,可以先合并回Develop分支.

新能源功能已經(jīng)開發(fā)完成了,這個時候合并到了Develop,這個時候小宇睿聯(lián)的又有新的需求需要開發(fā),由于新能源短期內(nèi)無法上線,目前線上的環(huán)境是小宇睿聯(lián)的功能,如何處理?

這種情況,建議從Master里拉出Bug分支進行開發(fā),流程參考Fix-bug.

Github flow工作流簡介

Github flow 是Git flow的簡化版猎唁，專門配合"持續(xù)發(fā)布"。它是 Github.com 使用的工作流程顷蟆。

流程

它只有一個長期分支诫隅，就是master，因此用起來非常簡單帐偎。

官方推薦的流程如下逐纬。

image.png

第一步：根據(jù)需求，從master拉出新分支削樊，不區(qū)分功能分支或補丁分支豁生。

第二步：新分支開發(fā)完成后兔毒，或者需要討論的時候，就向master發(fā)起一個pull request（簡稱PR）甸箱。

第三步：Pull Request既是一個通知育叁，讓別人注意到你的請求，又是一種對話機制芍殖，大家一起評審和討論你的代碼豪嗽。對話過程中，你還可以不斷提交代碼围小。

第四步：你的Pull Request被接受昵骤，合并進master，重新部署后肯适，原來你拉出來的那個分支就被刪除变秦。（先部署再合并也可。）

擴展討論

1. 如何將現(xiàn)有代碼切換過來
2. 如何培訓推廣

GEMINI修改分支樣例

遷移前分支狀況

master 最新迭代分支

pro 生產(chǎn)環(huán)境分支

fat 測試環(huán)境分支

5m 5米微循環(huán)分支

遷移計劃

1.從master新建一個develop分支

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout master
git checkout -b develop</pre>

|

2.把master分支重置到pro分支的分叉處,我的項目里查到的分叉處commit為 af8ac1ef66f3e2c932623eecd71296e19a2c2e9c

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git.exe reset --hard af8ac1ef66f3e2c932623eecd71296e19a2c2e9c
git.exe merge remotes/origin/pro</pre>

|

最終達到的效果:

1. master分支指向到了origin/pro
2. develop分支指向到了最新代碼

image.png

image.png

參考文檔

Git工作流程

A successful Git branching model

Understanding the GitHub flow

GitHub Flow