前言
在使用Git的過程中如果沒有清晰流程和規(guī)劃，否則每個人都提交一堆雜亂無章的commit,項目很快就會變得難以協(xié)調(diào)和維護(hù)稿静。
Git版本管理同樣需要一個清晰的流程和規(guī)范。
Vincent Driessen 為了解決這個問題提出了 A Successful Git Branching Model
以下是基于Vincent Driessen提出的Git Flow 流程圖 （非常清晰辕狰，圖片上的英文可以翻譯一下便于理解）
分支約定
主分支
主分支分為master分支和develop分支改备，是所有開發(fā)活動的核心分支。所有的開發(fā)活動產(chǎn)生的輸出物最終都會反映到主分支的代碼中, 生命周期為常駐蔓倍。
master 分支
master分支存放的是隨時可供在生產(chǎn)環(huán)境中部署的穩(wěn)定版本代碼
master分支保存官方發(fā)布版本歷史悬钳，release tag標(biāo)識不同的發(fā)布版本
一個項目只能有一個master分支
僅在發(fā)布新的可供部署的代碼時才更新master分支上的代碼
每次更新master，都需對master添加指定格式的tag偶翅，用于發(fā)布或回滾
master分支是保護(hù)分支默勾，不可直接push到遠(yuǎn)程倉master分支
master分支代碼只能被release分支或hotfix分支合并
develop 分支
develop分支是保存當(dāng)前最新開發(fā)成果的分支
一個項目只能有一個develop分支
develop分支衍生出各個feature分支
develop分支是保護(hù)分支，不可直接push到遠(yuǎn)程倉庫develop分支
develop分支不能與master分支直接交互
輔助分支
輔助分支分為feature分支聚谁、release 分支母剥、hotfix 分支，輔助分支主要用于組織軟件新功能的并行開發(fā)、簡化新功能開發(fā)代碼的跟蹤环疼、輔助完成版本發(fā)布工作以及對生產(chǎn)代碼的缺陷進(jìn)行緊急修復(fù)工作习霹。這些分支與主分支不同，通常只會在有限的時間范圍內(nèi)存在
feature 分支
使用規(guī)范：
命名規(guī)則：
feature/*develop分支的功能分支
feature分支使用develop分支作為它們的父類分支
以功能為單位從develop拉一個feature分支
每個feature分支顆粒要盡量小炫隶，以利于快速迭代和避免沖突
當(dāng)其中一個feature分支完成后淋叶，它會合并回develop分支
當(dāng)一個功能因為各種原因不開發(fā)了或者放棄了，這個分支直接廢棄等限，不影響develop分支
feature分支代碼可以保存在開發(fā)者自己的代碼庫中而不強(qiáng)制提交到主代碼庫里
feature分支只與develop分支交互爸吮，不能與master分支直接交互
如有幾個同事同時開發(fā)，需要分割成幾個小功能望门，每個人都需要從develop中拉出一個feature分支形娇，但是每個feature顆粒要盡量小，因為它需要我們能盡早merge回develop分支筹误，否則沖突解決起來就沒完沒了桐早。同時，當(dāng)一個功能因為各種原因不開發(fā)了或者放棄了厨剪，這個分支直接廢棄哄酝，不影響develop分支。
release 分支
使用規(guī)范：
命名規(guī)則：
release/*祷膳，“*”以本次發(fā)布的版本號為標(biāo)識release分支主要用來為發(fā)布新版的測試陶衅、修復(fù)做準(zhǔn)備
當(dāng)需要為發(fā)布新版做準(zhǔn)備時，從develop衍生出一個release分支
release分支可以從develop分支上指定commit派生出
release分支測試通過后直晨，合并到master分支并且給master標(biāo)記一個版本號
release分支一旦建立就將獨(dú)立搀军，不可再從其他分支pull代碼
必須合并回develop分支和master分支
release分支是為發(fā)布新的產(chǎn)品版本而設(shè)計的。在這個分支上的代碼允許做小的缺陷修正勇皇、準(zhǔn)備發(fā)布版本所需的各項說明信息（版本號罩句、發(fā)布時間、編譯時間等）敛摘。通過在release分支上進(jìn)行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交门烂，進(jìn)入新的軟件開發(fā)迭代周期。
當(dāng)develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計劃包含的軟件功能兄淫，并且已通過所有測試時屯远，我們就可以考慮準(zhǔn)備創(chuàng)建release分支了。而所有在當(dāng)前即將發(fā)布的版本之外的業(yè)務(wù)需求一定要確保不能混到release分支之內(nèi)（避免由此引入一些不可控的系統(tǒng)缺陷）拖叙。
成功的派生了release分支氓润，并被賦予版本號之后，develop分支就可以為“下一個版本”服務(wù)了薯鳍。所謂的“下一個版本”是在當(dāng)前即將發(fā)布的版本之后發(fā)布的版本。版本號的命名可以依據(jù)項目定義的版本號命名規(guī)則進(jìn)行。
hotfix 分支
使用規(guī)范：
命名規(guī)則：
hotfix/*hotfix分支用來快速給已發(fā)布產(chǎn)品修復(fù)bug或微調(diào)功能
只能從master分支指定tag版本衍生出來
一旦完成修復(fù)bug挖滤，必須合并回master分支和develop分支
master被合并后崩溪，應(yīng)該被標(biāo)記一個新的版本號
hotfix分支一旦建立就將獨(dú)立，不可再從其他分支pull代碼
除了是計劃外創(chuàng)建的以外斩松，hotfix分支與release分支十分相似：都可以產(chǎn)生一個新的可供在生產(chǎn)環(huán)境部署的軟件版本伶唯。
當(dāng)生產(chǎn)環(huán)境中的軟件遇到了異常情況或者發(fā)現(xiàn)了嚴(yán)重到必須立即修復(fù)的軟件缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復(fù)工作惧盹。
這樣做的顯而易見的好處是不會打斷正在進(jìn)行的develop分支的開發(fā)工作乳幸，能夠讓團(tuán)隊中負(fù)責(zé)新功能開發(fā)的人與負(fù)責(zé)代碼緊急修復(fù)的人并行的開展工作。
Git Flow 如何使用
-
Master/Develop 分支
所有在Master分支上的Commit應(yīng)該打上Tag钧椰，一般情況下Master不存在Commit粹断，Devlop分支基于Master分支創(chuàng)建
-
Feature 分支
Feature分支做完后，必須合并回Develop分支, 合并完分支后一般會刪點(diǎn)這個Feature分支嫡霞，畢竟保留下來意義也不大瓶埋。
-
Release 分支
Release分支基于Develop分支創(chuàng)建，打完Release分支之后诊沪，我們可以在這個Release分支上測試养筒，修改Bug等。同時端姚，其它開發(fā)人員可以基于Develop分支新建Feature (記自畏唷：一旦打了Release分支之后不要從Develop分支上合并新的改動到Release分支)發(fā)布Release分支時，合并Release到Master和Develop渐裸， 同時在Master分支上打個Tag記住Release版本號巫湘，然后可以刪除Release分支了。
-
Hotfix 分支
hotfix分支基于Master分支創(chuàng)建橄仆，開發(fā)完后需要合并回Master和Develop分支剩膘，同時在Master上打一個tag。
使用規(guī)范
所有使用了本規(guī)范的項目盆顾，必須嚴(yán)格規(guī)范操作怠褐，否則不予以合并代碼、提測您宪、打包上線等后續(xù)操作
基本要求
所有commit必須有注釋奈懒，內(nèi)容必須簡潔明了的描述本次commit涵蓋了哪些內(nèi)容。嚴(yán)禁注釋內(nèi)容過于簡單或不能明確表達(dá)提交內(nèi)容的宪巨！
合理控制提交內(nèi)容的顆粒度磷杏，一次commit含一個獨(dú)立功能點(diǎn)。嚴(yán)禁一次提交涵蓋多個功能項捏卓。
正確為每個項目設(shè)置Git提交用到的user.name和user.email信息极祸，以公司郵箱為準(zhǔn)，不可隨意設(shè)置以影響無法正確識別。 查看當(dāng)前項目配置信息的命令：
git config -l
commit提交規(guī)范
<type>(<scope>): <subject>
type
commit 的類型：
feat: 新功能遥金、新特性
fix: 修改 bug
perf: 更改代碼浴捆，以提高性能（在不影響代碼內(nèi)部行為的前提下，對程序性能進(jìn)行優(yōu)化）
refactor: 代碼重構(gòu)（重構(gòu)稿械，在不影響代碼內(nèi)部行為选泻、功能下的代碼修改）
docs: 文檔修改
style: 代碼格式修改, 注意不是 css 修改（例如分號修改）
test: 測試用例新增、修改
build: 影響項目構(gòu)建或依賴項修改
revert: 恢復(fù)上一次提交
ci: 持續(xù)集成相關(guān)文件修改
chore: 其他修改（不在上述類型中的修改）
release: 發(fā)布新版本
workflow: 工作流相關(guān)文件修改
scope
commit 影響的范圍, 比如: route, component, utils, build...
subject
commit 的概述
示例
fix
如果修復(fù)的這個BUG只影響當(dāng)前修改的文件美莫，可不加范圍页眯。如果影響的范圍比較大，要加上范圍描述厢呵。
例如這次 BUG 修復(fù)影響到全局窝撵，可以加個 global。如果影響的是某個目錄或某個功能述吸，可以加上該目錄的路徑忿族，或者對應(yīng)的功能名稱。
// 示例1
fix(global):修復(fù)checkbox不能復(fù)選的問題
// 示例2 下面圓括號里的 common 為通用管理的名稱
fix(common): 修復(fù)字體過小的BUG蝌矛，將通用管理下所有頁面的默認(rèn)字體大小修改為 14px
// 示例3
fix: value.length -> values.length
版本號(tag)
版本號(tag)命名規(guī)則：
主版本號.次版本號.修訂號道批，如2.1.13。(遵循GitHub語義化版本命名規(guī)范)版本號僅標(biāo)記于master分支入撒，用于標(biāo)識某個可發(fā)布/回滾的版本代碼
對master標(biāo)記tag意味著該tag能發(fā)布到生產(chǎn)環(huán)境
對master分支代碼的每一次更新(合并)必須標(biāo)記版本號
僅項目管理員有權(quán)限對master進(jìn)行合并和標(biāo)記版本號
項目權(quán)限
Git權(quán)限分管理員隆豹、開發(fā)者、瀏覽者三種類型
瀏覽者只能瀏覽代碼茅逮，無push璃赡、pull request等所有寫權(quán)限
開發(fā)者擁有瀏覽、push非主分支献雅、提交pull request工單權(quán)限
管理員擁有建立和管理Git項目碉考、合并分支和代碼、給master打tag版本號等權(quán)限
分支使用
每個Git項目固定含有上述所有分支類型挺身。主分支master和develop是保護(hù)分支侯谁，只能進(jìn)行合并請求，均不可直接提交代碼章钾。
功能需求或常規(guī)Bug修復(fù)墙贱，請從develop拉取feature分支；線上緊急問題修復(fù)贱傀，請從master拉去hotfix分支惨撇。
代碼提交
一個提交就代表解決一個問題
大問題適當(dāng)?shù)胤纸鉃槎鄠€小問題，以便每次小型提交都更易于理解
提交前本地代碼需要編譯成功府寒，并檢查一下提交的代碼 (這一步很重要魁衙，測試代碼报腔、簡單的邏輯錯誤都可以被發(fā)現(xiàn), 可以有效解決簡單粗心的bug產(chǎn)生)
參考資料：
