一. Git管理說(shuō)明

采用功能驅(qū)動(dòng)開(kāi)發(fā)（feature-driven develop ment欧穴，簡(jiǎn)稱(chēng)FDD）

需求是開(kāi)發(fā)的起點(diǎn)鸽捻，先有需求再有功能分支或者補(bǔ)丁分支说榆。完成開(kāi)發(fā)后渔隶，該分支就合并到常駐分支，然后被刪除.

采用Git Flow（Git工作流）的方式

"工作流程"在英語(yǔ)里纵顾，叫做"workflow"或者"flow"伍茄，原意是水流，比喻項(xiàng)目像水流那樣片挂，順暢幻林、自然地向前流動(dòng)，不會(huì)發(fā)生沖擊音念、對(duì)撞沪饺、甚至漩渦.

Git工作流.png

二. Git Flow

項(xiàng)目中長(zhǎng)期存在兩個(gè)分支: master 和 develop

常駐分支.png

項(xiàng)目中的三種短期分支

完成開(kāi)發(fā)遭居，該分支會(huì)合并到 develop 或 master 中啼器，合并完成之后該分支的生命周期結(jié)束，刪除該分支俱萍。

*是取通配符的意思端壳，用來(lái)代替不同的命名

GitFlow總覽.png

看圖說(shuō)話：

• 只有 master 和 develop 一直是實(shí)體線。說(shuō)明這兩條是常駐分支枪蘑。其他分支是階段性實(shí)體線损谦，用完就刪除。

• master 分支merge（版本發(fā)布或者bug修復(fù)）都要設(shè)置tag岳颇。

• master 分支只會(huì)被bug分支和 release 分支merge照捡。

• develop 只有創(chuàng)建的時(shí)候才跟 master 有關(guān)系。

• develop 分支支持小版本的開(kāi)發(fā)迭代（視情況而用）话侧，不需要再拉 feature 分支栗精。（嚴(yán)格上來(lái)講每一次版本都應(yīng)該拉 feature 分支）

• feature 分支只與 develop 分支有關(guān)系。是從 develop 中拉出來(lái)的瞻鹏，并且合并回 develop 悲立。 feature 分支之間沒(méi)有關(guān)系。

• release 分支只從 develop 拉出來(lái)乙漓， release 分支測(cè)試的bug级历，要及時(shí)merge到 develop ，最終 release 分支要合并到 master 和 develop 分支叭披，并刪除。

• bug分支是從 master 對(duì)應(yīng)tag節(jié)點(diǎn)拉取的玩讳。最后合并到 develop 和 master 分支涩蜘。（此時(shí)如有 release 分支也應(yīng)合并）合并到 master 上的時(shí)候也應(yīng)該設(shè)置tag。

三. 針對(duì)各個(gè)分支的說(shuō)明

1. master 分支

使用注意：

• 代碼庫(kù)必須有且只有一個(gè) master 分支熏纯，所有發(fā)布版本都在這個(gè)分支上發(fā)布同诫。

• 對(duì) master 分支使用gitlab的分支保護(hù)，僅管理者有權(quán)限樟澜。

• 每次發(fā)布打tag误窖，便于處理線上bug，拉取bug分支秩贰。

• 除了從pre-release 或生產(chǎn)環(huán)境Bug修復(fù)分支進(jìn)行merge霹俺，不接受任何其它修改。

• 禁止將 master 分支merge到其他分支毒费。

master分支.png

2. develop 分支

開(kāi)發(fā)環(huán)境的穩(wěn)定分支丙唧，公共開(kāi)發(fā)環(huán)境基于該分支構(gòu)建。

注意點(diǎn)：

• develop 分支來(lái)源于 master 分支觅玻，之后就跟 master 無(wú)關(guān)了想际。

• develop 分支一定是大于等于 master 分支的培漏。

• 嚴(yán)禁 master 分支合并到 develop 分支的操作。

• develop 分支最好不好做版本開(kāi)發(fā)胡本，版本開(kāi)發(fā)應(yīng)該在對(duì)應(yīng)的 feature 分支上牌柄。

develop分支.png

3. feature 分支

為了開(kāi)發(fā)某個(gè)特定功能，從 develop 分支上面分出來(lái)的侧甫。開(kāi)發(fā)完成后珊佣，要merge到 develop 分支。

注意點(diǎn)：

• 通常用 feature -name命名闺骚。
• 通常是在 develop 分支拉取的彩扔，如果需要和線上版本保持一致，也可以從 master 拉取僻爽。

• 功能分支屬于臨時(shí)分支虫碉，合并完就結(jié)束生命周期，執(zhí)行刪除操作胸梆。

  
  
  feature分支.png

feature 分支的使用說(shuō)明：

• 當(dāng)前僅有一條 feature 分支開(kāi)發(fā)的情況

  從當(dāng)前的 develop 分支拉someOne分支敦捧，在someOne分支上進(jìn)行開(kāi)發(fā)，要將該分支推送為線上分支（防止意外發(fā)生碰镜，比如電腦壞了...）兢卵。如果需要提測(cè)，將該分支合并到 develop 分支上绪颖，并基于 develop 拉 release 分支秽荤。

• 當(dāng)前有多條 feature 并行的情況

  如果要開(kāi)發(fā)someOne版本，從當(dāng)前的 develop 分支拉取someOne分支柠横，someOne功能未開(kāi)發(fā)結(jié)束窃款，這個(gè)過(guò)程中來(lái)了anotherOne版本，應(yīng)該從 develop 對(duì)應(yīng)的someOne分支節(jié)點(diǎn)前（不包含someOne代碼的最新節(jié)點(diǎn)）拉anotherOne的分支牍氛。如果出現(xiàn)當(dāng)前不適合合并到 develop 的情況晨继，可以在當(dāng)前的 feature 操作版本提測(cè)。

4. release 分支

預(yù)發(fā)布分支搬俊，又叫測(cè)試分支紊扬，是一個(gè)臨時(shí)分支。通常用于合并到 master 之前拉一個(gè)預(yù)發(fā)布分支用于測(cè)試唉擂。

注意點(diǎn)：

• 通常用release-*命名

• 預(yù)發(fā)布分支是從 develop 分支拉取的餐屎。

• 預(yù)發(fā)布分支的bug，在該分支處理楔敌，處理完同步到 develop 上啤挎。

• 預(yù)發(fā)布分支測(cè)試完成，合并到 develop 和 master 分支上。

5. hotfix分支

修復(fù)線上bug一般拉一個(gè)叫 hotfix-* 分支庆聘。其他的開(kāi)發(fā)bug分支叫 bugfix 分支胜臊。這兩種分支都屬于臨時(shí)分支，合并完成伙判，及時(shí)刪除該分支象对。

因?yàn)榫€上bug和開(kāi)發(fā)bug處理方式不同，最好還用分區(qū)一下分支的命名

bug產(chǎn)生的分支情況：

• master 分支

bug產(chǎn)生于 master 分支宴抚，需要從 master 對(duì)應(yīng)的tag節(jié)點(diǎn)拉取hotfix分支勒魔，做完修復(fù)之后，用這個(gè)hotfix

打包測(cè)試菇曲，發(fā)布上線冠绢。上線成功之后，將該條hotfix分支分別合并到 master 和 develop 上常潮，并刪除該hotfix分支弟胀。（如有需要還要合并到需要的 feature 和 release 分支）

思考為什么要從bug分支打包上線?

• develop 分支

bug產(chǎn)生于 develop 分支，在發(fā)現(xiàn)該bug的節(jié)點(diǎn)喊式，拉取bugfix分支孵户，修復(fù)完成，合并回 develop 分支岔留。并做刪除操作夏哭。（如有需要還要合并到 feature 和 release 分支）

• feature 分支

在 feature 上發(fā)現(xiàn)的bug，要對(duì)該bug做區(qū)分是否屬于該功能分支上的献联。如果屬于該分支竖配，修改即可。如果屬于 develop 分支里逆，要在 develop 上找到合適的commit械念，拉取bugfix分支，修改完成之后合并到 develop 上运悲。（如有需要還要合并到需要的 feature 和 release 分支）

四. 流程規(guī)范

1. 正常開(kāi)發(fā)流程

• 從 develop 分支切出一個(gè)新分支，根據(jù)需求區(qū)分功能還是bug分支项钮。

  如果新功能開(kāi)發(fā)就是 feature-* 分支班眯，如果是dev的bug修復(fù)就是 fixbug-* 分支。

• 開(kāi)發(fā)者完成開(kāi)發(fā)烁巫，提交分支到遠(yuǎn)程倉(cāng)庫(kù)署隘。

• 開(kāi)發(fā)者發(fā)起 merge 請(qǐng)求（嚴(yán)格的話采用 Merge Request），將新分支請(qǐng)求merge到 develop 分支亚隙，并提醒code reviewer進(jìn)行review磁餐。

• code reviewer對(duì)代碼review之后，若無(wú)問(wèn)題，則接受merge請(qǐng)求诊霹，新分支merge到 develop 分支羞延，同時(shí)可刪除新建分支；若有問(wèn)題脾还，則不能進(jìn)行merge伴箩，可close該請(qǐng)求，同時(shí)通知開(kāi)發(fā)者在新分支上進(jìn)行相應(yīng)調(diào)整鄙漏。調(diào)整完后提交代碼重復(fù)review流程嗤谚。

• 轉(zhuǎn)測(cè)時(shí)，直接從當(dāng)前 develop 分支拉 release 分支怔蚌，構(gòu)建測(cè)試環(huán)境完成轉(zhuǎn)測(cè)巩步。

• 測(cè)試中，如果發(fā)現(xiàn)bug桦踊，就在 release 分支修改椅野，修改完成merge到 develop 分支。

• 測(cè)試完成后钞钙，基于pre- release 分支打包完成上線工作鳄橘。上線完成之后，merge到 master 分支和dev分支芒炼，并對(duì) master 分支打tag瘫怜，tag一般采用線上app的版本號(hào)。
  

  正常開(kāi)發(fā)流程.png

2. 生產(chǎn)環(huán)境bug修復(fù)

生產(chǎn)環(huán)境的Bug分兩種情況：

• 非緊急Bug或優(yōu)化：非關(guān)鍵業(yè)務(wù)流程問(wèn)題本刽，僅影響用戶使用體驗(yàn)鲸湃，或出現(xiàn)頻率較小等，為非緊急Bug子寓，可規(guī)劃到后續(xù)版本, 作為功能需求進(jìn)行修復(fù)暗挑。

• 緊急Bug：嚴(yán)重影響用戶使用的為緊急Bug，需立即進(jìn)行修復(fù)斜友。如關(guān)鍵業(yè)務(wù)流程存在問(wèn)題炸裆，影響用戶正常的業(yè)務(wù)行為。

緊急Bug修復(fù)：

• 需要從 master 分支切出一個(gè)bug修復(fù)分支
• 完成修復(fù)之后鲜屏，將該分支代碼提交測(cè)試烹看。如果問(wèn)題繼續(xù)在當(dāng)前分支修改。
• 驗(yàn)證完成洛史，需要同時(shí)merge到 master 分支與 develop 分支惯殊。

3. dev環(huán)境bug修復(fù)

• 從對(duì)應(yīng)的節(jié)點(diǎn)拉取 bugfix 分支
• 修復(fù)完成，如需測(cè)試接入也殖，用該分支提測(cè)土思。
• 驗(yàn)證完成，將 bugfix 分支合并到 develop 分支上。
• 當(dāng)前如果存在 release 分支己儒，也應(yīng)該合并到該分支崎岂。
• 如果有暫時(shí)不能合并到 develop 分支的 feature 分支，也要判斷是否需要合并址愿。

五. 小技巧

1. Merge Request

功能分支合并請(qǐng)求该镣，可以使用Gitlab的 Merge Request 功能。本質(zhì)是一種對(duì)話機(jī)制响谓，你可以在提交的時(shí)候损合，@相關(guān)人員，引起他們的注意娘纷。

Pull request.png

2. 分支保護(hù)

master分支應(yīng)該受到保護(hù)嫁审，不是每個(gè)人都可以修改這個(gè)分支，以及擁有審批 Merge Request 的權(quán)力赖晶。Gitlab默認(rèn)提供了該功能律适。

3. Merge節(jié)點(diǎn)

Git有兩種合并：一種是"直進(jìn)式合并"（fast forward），不生成單獨(dú)的合并節(jié)點(diǎn)遏插；另一種是"非直進(jìn)式合并"（none fast-forword）捂贿，會(huì)生成單獨(dú)節(jié)點(diǎn)。

前者不利于保持commit信息的清晰胳嘲，也不利于以后的回滾厂僧，建議總是采用后者（即使用--no-ff參數(shù)）。只要發(fā)生合并了牛，就要有一個(gè)單獨(dú)的合并節(jié)點(diǎn)颜屠。

merge節(jié)點(diǎn).png

六. 說(shuō)明

引用聲明

• 圖片來(lái)源 Git Flow總覽

• 阮一峰 Git工作流程