概況

當(dāng)前文檔包涵開(kāi)發(fā)流程規(guī)范與上線（OP）流程規(guī)范疆柔。

通過(guò)規(guī)范開(kāi)發(fā)流程可以嚴(yán)格控制線上分支的代碼質(zhì)量及穩(wěn)定性。使用成熟的工作流程模型镶柱，可以使團(tuán)隊(duì)協(xié)作更加流暢旷档。

通過(guò)規(guī)范上線（OP）流程，保證線上環(huán)境的穩(wěn)定歇拆，明確職責(zé)鞋屈。

涉及人員

• 研發(fā)工程師
• 代碼審核員（技術(shù)負(fù)責(zé)人或由技術(shù)負(fù)責(zé)人指定的研發(fā)工程師范咨，不可以是開(kāi)發(fā)者本人）
• 產(chǎn)品經(jīng)理
• 測(cè)試工程師（未到崗前，產(chǎn)品經(jīng)理負(fù)責(zé)）

多人協(xié)作流程與規(guī)范

一厂庇、工作流

選用GitFlow工作流模式作為協(xié)作流程規(guī)范渠啊。

1、gitflow

Gitflow工作流定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型权旷。雖然比功能分支工作流復(fù)雜幾分替蛉，但提供了一個(gè)健壯的用于管理大型項(xiàng)目的框架。

Gitflow為不同的分支分配一個(gè)很明確的角色拄氯，并定義分支之間如何和什么時(shí)候進(jìn)行交互躲查。 除了使用功能分支外在做Bug修復(fù)、維護(hù)和預(yù)發(fā)布時(shí)也使用各自的分支译柏。同時(shí)通過(guò)Pull Requests镣煮、隔離實(shí)驗(yàn)性開(kāi)發(fā)實(shí)現(xiàn)更高效的協(xié)作。

2鄙麦、工作方式

Gitflow工作流仍然用一個(gè)遠(yuǎn)程倉(cāng)庫(kù)作為所有開(kāi)發(fā)者的交互中心典唇。和其它的工作流一樣，開(kāi)發(fā)者在本地工作并push分支到中央倉(cāng)庫(kù)中黔衡。

二蚓聘、主要分支: Master腌乡、Develop

Gitflow工作流使用2個(gè)分支來(lái)記錄項(xiàng)目的歷史盟劫。master分支存儲(chǔ)了正式發(fā)布的歷史，而develop分支作為功能的集成分支与纽。 這樣也方便master分支上的所有提交分配一個(gè)版本號(hào)侣签。

• Master(綠色): 永遠(yuǎn)處在 production-ready 狀態(tài)
• Develop(橙色): 最新的下次發(fā)布開(kāi)發(fā)狀態(tài)

image

三、支援性（臨時(shí)）分支:

1急迂、Feature功能分支

每個(gè)新功能位于一個(gè)自己的分支影所，這樣可以push到中央倉(cāng)庫(kù)以備份和協(xié)作。 但功能分支不是從master分支上拉出新分支僚碎，而是使用develop分支作為父分支猴娩。當(dāng)新功能完成時(shí)，合并回develop分支勺阐。 新功能提交應(yīng)該從不直接與master分支交互卷中。

Feature(藍(lán)色): 開(kāi)發(fā)新功能都從 develop 分支出來(lái)，完成后 merge 回 develop

image

2渊抽、release發(fā)布分支

一旦develop分支上有了做一次發(fā)布（或者說(shuō)快到了既定的發(fā)布日）的足夠功能蟆豫，就從develop分支上fork一個(gè)發(fā)布分支。 新建的分支用于開(kāi)始發(fā)布循環(huán)懒闷，所以從這個(gè)時(shí)間點(diǎn)開(kāi)始之后新的功能不能再加到這個(gè)分支上—— 這個(gè)分支只應(yīng)該做Bug修復(fù)十减、文檔生成和其它面向發(fā)布任務(wù)栈幸。 一旦對(duì)外發(fā)布的工作都完成了，發(fā)布分支合并到master分支并分配一個(gè)版本號(hào)打好Tag帮辟。 另外速址，這些從新建發(fā)布分支以來(lái)的做的修改要合并回develop分支。

使用一個(gè)用于發(fā)布準(zhǔn)備的專門分支由驹，使得一個(gè)團(tuán)隊(duì)可以在完善當(dāng)前的發(fā)布版本的同時(shí)壳繁，另一個(gè)團(tuán)隊(duì)可以繼續(xù)開(kāi)發(fā)下個(gè)版本的功能。 這也打造定義良好的開(kāi)發(fā)階段（比如荔棉，可以很輕松地說(shuō)闹炉，『這周我們要做準(zhǔn)備發(fā)布版本4.0』，并且在倉(cāng)庫(kù)的目錄結(jié)構(gòu)中可以實(shí)際看到）润樱。

常用的分支約定：

用于新建發(fā)布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*

Release(黃色): 準(zhǔn)備要 release 的版本渣触，只修 bugs。從 develop 分支出來(lái)壹若，完成后 merge 回 master 和 develop

image

3嗅钻、hotfix維護(hù)分支

維護(hù)分支或說(shuō)是熱修復(fù)（hotfix）分支用于生成快速給產(chǎn)品發(fā)布版本（production releases）打補(bǔ)丁，這是唯一可以直接從master分支fork出來(lái)的分支店展。 修復(fù)完成养篓，修改應(yīng)該馬上合并回master分支和develop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號(hào)打好Tag赂蕴。

為Bug修復(fù)使用專門分支柳弄，讓團(tuán)隊(duì)可以處理掉問(wèn)題而不用打斷其它工作或是等待下一個(gè)發(fā)布循環(huán)。 你可以把維護(hù)分支想成是一個(gè)直接在master分支上處理的臨時(shí)發(fā)布概说。

• Hotfix(灰色): 等不及 release 版本就必須馬上修 master 趕上線的情況碧注。會(huì)從 master 分支出來(lái)，完成后 merge 回 master 和 develop

image

四糖赔、代碼Review

使用pull request進(jìn)行代碼review

在Gitflow工作流中使用Pull Request讓開(kāi)發(fā)者在發(fā)布分支或是維護(hù)分支上工作時(shí)萍丐， 可以有個(gè)方便的地方對(duì)關(guān)于發(fā)布分支或是維護(hù)分支的問(wèn)題進(jìn)行交流。

當(dāng)一個(gè)功能放典、發(fā)布或是熱修復(fù)分支需要Review時(shí)逝变，開(kāi)發(fā)者簡(jiǎn)單發(fā)起一個(gè)Pull Request， 團(tuán)隊(duì)的其它成員會(huì)通過(guò)Bitbucket收到通知奋构。

新功能一般合并到develop分支壳影，而發(fā)布和熱修復(fù)則要同時(shí)合并到develop分支和master分支上。 Pull Request可能用做所有合并的正式管理声怔。

image

OP流程

規(guī)范開(kāi)發(fā)協(xié)作流程之后态贤，其實(shí)OP流程就相對(duì)簡(jiǎn)單了。

首先規(guī)定所有代碼合并到Develop醋火、或Master都經(jīng)過(guò)了測(cè)試悠汽、review及驗(yàn)收箱吕。

此時(shí)OP只需要執(zhí)行線上部署即可。

一柿冲、基本約定

• master 技術(shù)負(fù)責(zé)人 讀寫茬高，開(kāi)發(fā) 只讀
• develop 技術(shù)負(fù)責(zé)人 讀寫，開(kāi)發(fā) 只讀
• release/hotfix/hotfix 等需要合并到 master的分支需要由技術(shù)負(fù)責(zé)人創(chuàng)建
• 其它臨時(shí)分支假抄，ALL 讀寫

二怎栽、一般開(kāi)發(fā)任務(wù)的OP流程

image

三、緊急任務(wù)的OP流程

image

職責(zé)分工

一宿饱、產(chǎn)品經(jīng)理

• 參與技術(shù)方案確認(rèn)
• 預(yù)上線測(cè)試
• 線上回歸及后續(xù)跟進(jìn)

二熏瞄、研發(fā)工程師

• 代碼開(kāi)發(fā)、bug修復(fù)（必須自測(cè)完成才能提交）
• 配合預(yù)上線測(cè)試

1谬以、一般開(kāi)發(fā)

（1）强饮、更新版本庫(kù)

git pull origin master:master
git pull origin develop:develop

（2）、創(chuàng)建功能分支

git checkout develop
git checkout -b feature/<功能名稱>

（3）为黎、開(kāi)發(fā)和測(cè)試

（4）邮丰、提交功能分支

git push origin feature/<功能名稱>

（5）、通過(guò)gitlab申請(qǐng)review (合并目標(biāo)develop)

（6）铭乾、解決沖突

git checkout develop
git pull origin develop:develop
git merge feature/<功能名稱>

（7）剪廉、提交合并結(jié)果

git push origin develop: feature/<功能名稱>

（8）、檢查通過(guò)

git branch -D feature/<功能名稱>

2炕檩、緊急修復(fù)

（1）斗蒋、獲取修復(fù)用分支

git checkout master
git pull origin master:master
git checkout -b hotfix/<編號(hào)>

（2）、開(kāi)發(fā)和測(cè)試

（3）捧书、提交功能分支

git push origin hotfix/<編號(hào)>

（4）吹泡、通過(guò)gitlab申請(qǐng)review (合并目標(biāo)master)

（5）骤星、解決沖突

git checkout master
git pull origin master:master
git merge hotfix/<編號(hào)>

（6）经瓷、提交合并結(jié)果

git push origin master:hotfix/<編號(hào)>

（7）、檢查通過(guò)

git branch -D hotfix/<編號(hào)>

3洞难、預(yù)上線集成

（1）舆吮、獲取集成分支

git fetch origin release/<編號(hào)>: release /<編號(hào)> git checkout release /<編號(hào)>

（2）、測(cè)試队贱、微調(diào) （嚴(yán)禁引入新功能和大的修改色冀，針對(duì)某一個(gè)bug或功能超過(guò)50行的修改即認(rèn)為大型修改，本次上線終止）

（3）柱嫌、提交功能分支

git push origin release /<編號(hào)>

（4）锋恬、通過(guò)gitlab申請(qǐng)review (合并目標(biāo)master)

（5）、解決沖突

git checkout master
git pull origin master:master
git merge release /<編號(hào)>

（6）编丘、提交合并結(jié)果

git push origin master: release /<編號(hào)>

（7）与学、檢查通過(guò)

git branch -D release /<編號(hào)>

4彤悔、代碼審核員

代碼review，結(jié)果合并

5索守、技術(shù)負(fù)責(zé)人

任務(wù)分配

臨時(shí)分支創(chuàng)建工作：release\hotfix\hotfix

代碼review晕窑，結(jié)果合并（結(jié)果需要同時(shí)合并到master、develop）

6卵佛、OP

按郵件說(shuō)明杨赤，將master指定版本上線

示例

下面的示例演示本工作流如何用于管理單個(gè)發(fā)布循環(huán)。假設(shè)你已經(jīng)創(chuàng)建了一個(gè)中央倉(cāng)庫(kù)截汪。

一疾牲、創(chuàng)建開(kāi)發(fā)分支

image

第一步為master分支配套一個(gè)develop分支。簡(jiǎn)單來(lái)做可以[本地創(chuàng)建一個(gè)空的develop分支衙解，push到服務(wù)器上：

git branch develop
git push -u origin develop

以后這個(gè)分支將會(huì)包含了項(xiàng)目的全部歷史说敏，而master分支將只包含了部分歷史。其它開(kāi)發(fā)者這時(shí)應(yīng)該克隆中央倉(cāng)庫(kù)丢郊，建好develop分支的跟蹤分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

現(xiàn)在每個(gè)開(kāi)發(fā)都有了這些歷史分支的本地拷貝盔沫。

二、程序員A和程序員B開(kāi)始開(kāi)發(fā)新功能

image

這個(gè)示例中枫匾，程序員A和程序員B開(kāi)始各自的功能開(kāi)發(fā)架诞。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于master分支干茉，而是應(yīng)該基于develop分支：

git checkout -b some-feature develop

他們用老套路添加提交到各自功能分支上：編輯谴忧、暫存、提交：

git status
git add <some-file> 
git commit

三角虫、程序員A完成功能開(kāi)發(fā)

image

添加了提交后沾谓，程序員A覺(jué)得她的功能OK了。如果團(tuán)隊(duì)使用Pull Requests戳鹅，這時(shí)候可以發(fā)起一個(gè)用于合并到develop分支均驶。 否則她可以直接合并到她本地的develop分支后push到中央倉(cāng)庫(kù)：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一條命令在合并功能前確保develop分支是最新的。注意枫虏，功能決不應(yīng)該直接合并到master分支妇穴。 沖突解決方法和集中式工作流一樣。

四隶债、程序員A開(kāi)始準(zhǔn)備發(fā)布

image

這個(gè)時(shí)候程序員B正在實(shí)現(xiàn)他的功能腾它，程序員A開(kāi)始準(zhǔn)備她的第一個(gè)項(xiàng)目正式發(fā)布。 像功能開(kāi)發(fā)一樣死讹，她用一個(gè)新的分支來(lái)做發(fā)布準(zhǔn)備瞒滴。這一步也確定了發(fā)布的版本號(hào)：

git checkout -b release-0.1 develop

這個(gè)分支是清理發(fā)布、執(zhí)行所有測(cè)試赞警、更新文檔和其它為下個(gè)發(fā)布做準(zhǔn)備操作的地方妓忍，像是一個(gè)專門用于改善發(fā)布的功能分支稀并。

只要程序員A創(chuàng)建這個(gè)分支并push到中央倉(cāng)庫(kù)，這個(gè)發(fā)布就是功能凍結(jié)的单默。任何不在develop分支中的新功能都推到下個(gè)發(fā)布循環(huán)中碘举。

五、程序員A完成發(fā)布

image

一旦準(zhǔn)備好了對(duì)外發(fā)布搁廓，程序員A合并修改到master分支和develop分支上引颈，刪除發(fā)布分支。合并回develop分支很重要境蜕，因?yàn)樵诎l(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的蝙场。 另外，如果程序員A的團(tuán)隊(duì)要求Code Review粱年，這是一個(gè)發(fā)起Pull Request的理想時(shí)機(jī)售滤。

git checkout master
git merge release-0.1 git push
git checkout develop
git merge release-0.1 git push
git branch -d release-0.1

發(fā)布分支是作為功能開(kāi)發(fā)（develop分支）和對(duì)外發(fā)布（master分支）間的緩沖。只要有合并到master分支台诗，就應(yīng)該打好Tag以方便跟蹤完箩。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各種勾子（hook），即倉(cāng)庫(kù)有事件發(fā)生時(shí)觸發(fā)執(zhí)行的腳本拉队。 可以配置一個(gè)勾子弊知，在你push中央倉(cāng)庫(kù)的master分支時(shí)，自動(dòng)構(gòu)建好對(duì)外發(fā)布粱快。

六秩彤、最終用戶發(fā)現(xiàn)bug

image

對(duì)外發(fā)布后，程序員A回去和程序員B一起做下個(gè)發(fā)布的新功能開(kāi)發(fā)事哭，直到有最終用戶開(kāi)了一個(gè)Ticket抱怨當(dāng)前版本的一個(gè)Bug漫雷。 為了處理Bug，程序員A（或程序員B）從master分支上拉出了一個(gè)維護(hù)分支鳍咱，提交修改以解決問(wèn)題降盹，然后直接合并回master分支：

git checkout -b issue-#001 master # Fix the bug
git checkout master
git merge issue-#001
git push

就像發(fā)布分支，維護(hù)分支中新加這些重要修改需要包含到develop分支中流炕，所以程序員A要執(zhí)行一個(gè)合并操作澎现。然后就可以安全地刪除這個(gè)分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

到了這里，但愿你對(duì)集中式工作流每辟、功能分支工作流和Gitflow工作流已經(jīng)感覺(jué)很舒適了。 你應(yīng)該也牢固的掌握了本地倉(cāng)庫(kù)的潛能干旧，push/pull模式和Git健壯的分支和合并模型渠欺。

記住，這里演示的工作流只是可能用法的例子椎眯，而不是在實(shí)際工作中使用Git不可違逆的條例挠将。 所以不要畏懼按自己需要對(duì)工作流的用法做取舍胳岂。不變的目標(biāo)就是讓Git為你所用。