前言

Gitflow 工作流是一種版本控制流程，主要適用于較大規(guī)模的團(tuán)隊(duì)。這個(gè)流程在團(tuán)隊(duì)中進(jìn)行合作時(shí)可以避免沖突，并能快速地完成項(xiàng)目，因此在很多軟件開發(fā)團(tuán)隊(duì)中都被廣泛應(yīng)用。通過使用 Gitflow 工作流，我們可以更好地管理代碼的修改、版本的發(fā)布和協(xié)作，從而提高軟件開發(fā)的效率和質(zhì)量。在本篇文章中，我們將模擬一次典型的 Gitflow 工作流流程，讓大家更好地理解這個(gè)工作流的工作流程和要點(diǎn)。

Gitflow 背景

“Gitflow 工作流程模型”的理念源自 Vincent Driessen（文森特·德里森）的深度研究與實(shí)踐經(jīng)驗(yàn)。在參與團(tuán)隊(duì)項(xiàng)目開發(fā)時(shí)，引入了 Gitflow 開發(fā)模型，之后又于2010年1月5日在一篇博客《A successful Git branching model》中詳細(xì)闡述了該模型的理論基礎(chǔ)及具體執(zhí)行方式，并通過圖表和實(shí)例進(jìn)行解釋，使讀者能夠更清晰、直觀地理解并應(yīng)用該模型。

這篇博客文章在軟件開發(fā)領(lǐng)域引起了極大反響，被廣泛傳播和引用，為開發(fā)人員提供了一套結(jié)構(gòu)嚴(yán)謹(jǐn)且可擴(kuò)展的分支管理策略，從而提高工作效率和代碼質(zhì)量。如今，它已經(jīng)成為使用 Git 進(jìn)行團(tuán)隊(duì)協(xié)作和版本控制的開發(fā)者首要參照模型。

博客中的工作模型圖如下：

Gitflow 中的分支模型

在 Gitflow 工作流程中，依據(jù)分支的壽命周期，我們可以將它們劃分為長(zhǎng)期分支和短期分支。

長(zhǎng)期分支主要用于綜合及管理諸多短期分支的代碼，以此確保代碼庫(kù)的整體框架和穩(wěn)定性，同時(shí)協(xié)助團(tuán)隊(duì)更加高效地管理和追蹤各分支的進(jìn)展及狀態(tài)。通常，長(zhǎng)期分支主要包括主分支（Main）和開發(fā)分支（Develop）這兩部分：

• 主分支（Main）：該分支主要用于儲(chǔ)存穩(wěn)定版發(fā)布版本的代碼，這是一個(gè)永不刪除的分支，只會(huì)接受由 Release 或 Hotfix 分支合并的代碼。同時(shí)，當(dāng) Release 分支和 Hotfix分支被合并回 Main 分支后，我們會(huì)添加一個(gè)標(biāo)簽，以標(biāo)記該版本的發(fā)布日期及版本序號(hào)等重要信息。過為每個(gè)版本打上標(biāo)簽，可以輕松地跟蹤和回滾到特定的版本。
• 開發(fā)分支（Develop）：開發(fā)分支基于主分支建立。該分支包含了當(dāng)前正進(jìn)行的所有功能開發(fā)和錯(cuò)誤修復(fù)工作，這也是一個(gè)持久性的分支。Develop 分支一般會(huì)接受來自 Feature 分支、 Release 分支和 Hotfix 分支的代碼合并。

至于短期分支，主要是在項(xiàng)目開發(fā)歷程中用于臨時(shí)任務(wù)的分支，其生命周期相對(duì)較短，如：

• 功能分支（Feature）：功能分支主要用于開發(fā)新功能的開發(fā)。是從 Develop 分支創(chuàng)建，每個(gè)新功能都應(yīng)在一個(gè)單獨(dú)的 Feature 分支上進(jìn)行開發(fā)，一旦功能開發(fā)完畢并通過測(cè)試，功能分支便會(huì)被合并回 Develop 分支。

• 補(bǔ)丁分支（Hotfix）：補(bǔ)丁分支則主要用于修復(fù)線上問題的分支。若在主分支 Main 上發(fā)現(xiàn)問題需要修復(fù)，那么我們會(huì)從 Main 分支上創(chuàng)建一個(gè) Hotfix 分支進(jìn)行修復(fù)，修復(fù)完成后，Hotfix 分支將被合并回 Main 分支和 Develop 分支，以保障修復(fù)過的錯(cuò)誤能在當(dāng)前和未來的版本中得以修正。

• 發(fā)布分支（Release）：發(fā)布分支用于準(zhǔn)備發(fā)布一個(gè)穩(wěn)定版的代碼，在 Release 分支上進(jìn)行最后的測(cè)試和修復(fù)，以確保代碼質(zhì)量和穩(wěn)定性。一旦 Release 分支準(zhǔn)備好發(fā)布，它將被合并回 Develop 分支和 Main 分支，以便在發(fā)布穩(wěn)定版時(shí)使用。

Gitflow 的版本號(hào)管理

版本號(hào)的目的是提供一種明確和一致的方式來標(biāo)識(shí)軟件版本，使開發(fā)者和用戶可以更清晰地了解版本的變化和影響，有助于管理依賴關(guān)系和追蹤版本的演進(jìn)。

目前常見的版本號(hào)格式定義是語義化版本規(guī)范，即所謂的"語義化版本控制（Semantic Versioning)"，也叫作"SemVer"標(biāo)準(zhǔn)。它是一種用于標(biāo)識(shí)和管理軟件版本的規(guī)范，被廣泛應(yīng)用于軟件開發(fā)。"SemVer"詳細(xì)地界定了版本號(hào)的格式、具體所代表的含義以及整體更新原則，其根本宗旨就是為了讓所有人都能以一致、確定的方式去描述和評(píng)估每次軟件變動(dòng)所帶來的影響大小。

按照語義化版本控制的規(guī)范，一個(gè)版本號(hào)由三個(gè)部分組成：主版本號(hào)、次版本號(hào)和修訂號(hào)，形式為 MAJOR.MINOR.PATCH ，每個(gè)部分都是非負(fù)整數(shù)，起始值為 0：

• 主版本號(hào)（MAJOR 「大版本」）：當(dāng)進(jìn)行不兼容的 API 變動(dòng)或重大改進(jìn)時(shí)增加。如果新版本與舊版本不兼容，用戶可能需要修改代碼才能適配新版本。
• 次版本號(hào)（MINOR 「小版本」）：當(dāng)添加功能或進(jìn)行向后兼容的改進(jìn)時(shí)增加。新功能的引入不會(huì)破壞現(xiàn)有的 API，但用戶可以利用新功能進(jìn)行開發(fā)。
• 修訂號(hào)（PATCH 「修補(bǔ)版本」）：用于修復(fù) Bug 或進(jìn)行其他小的改動(dòng)，不會(huì)引入新的功能或破壞現(xiàn)有的 API。

此外，語義化版本控制還支持在版本號(hào)后面添加預(yù)發(fā)布標(biāo)識(shí)和構(gòu)建號(hào)。

• 預(yù)發(fā)布標(biāo)識(shí)（Pre-release）：用于標(biāo)識(shí)測(cè)試階段的預(yù)發(fā)布版本，例如 alpha、beta、rc 等。預(yù)發(fā)布版本在正式發(fā)布之前進(jìn)行測(cè)試和反饋。
• 構(gòu)建號(hào)（Build Metadata）：用于標(biāo)識(shí)每個(gè)構(gòu)建的唯一編號(hào)，通常用于區(qū)分不同構(gòu)建的細(xì)微差異。

例如對(duì)于版本號(hào) v1.0.0，它代表著首個(gè)正式版本的發(fā)布。在這個(gè)版本中，可以期待有穩(wěn)定的功能和已經(jīng)修復(fù)的錯(cuò)誤，但不會(huì)有任何新的重大功能引入。這個(gè)版本標(biāo)記著軟件的第一個(gè)里程碑，可以作為后續(xù)版本的基礎(chǔ)。

注：版本號(hào)的具體規(guī)則和含義可能因團(tuán)隊(duì)或項(xiàng)目而異。因此在實(shí)際使用中，可以根據(jù)項(xiàng)目的需求和團(tuán)隊(duì)的約定來解釋和定義版本號(hào)的含義。

簡(jiǎn)單模擬 Gitflow 工作流

假設(shè)我們有一個(gè)新的項(xiàng)目，需要使用 Gitflow 工作流進(jìn)行代碼管理和協(xié)作開發(fā)，Gitflow 工作流過程如下：

1. 首先，在項(xiàng)目的開發(fā)階段，我們需要?jiǎng)?chuàng)建一個(gè)空的 Git 倉(cāng)庫(kù)，并初始化為一個(gè)新的項(xiàng)目；從空倉(cāng)庫(kù)創(chuàng)建一個(gè) Main 主分支，用于存儲(chǔ)穩(wěn)定版本的代碼，部署生產(chǎn)環(huán)境：

   

2. 然后，基于 Main 主分支創(chuàng)建一個(gè) Develop 開發(fā)分支，后續(xù)所有的開發(fā)工作都將在這個(gè)分支上進(jìn)行：

   

3. 根據(jù)團(tuán)隊(duì)的需求，為開發(fā)人員分配兩個(gè)開發(fā)任務(wù)：

   • 用戶登錄：用于允許用戶在網(wǎng)站進(jìn)行登錄。此功能將作為 1.0 版本的一部分上線。
   • 在線支付：用于在網(wǎng)站中實(shí)現(xiàn)在線支付功能。此功能將作為 2.0 版本的一部分上線。

   明確功能后，基于 Develop 開發(fā)分支創(chuàng)建對(duì)應(yīng)的 Feature 功能分支：

   

4. 當(dāng)用戶登錄功能在 Feature 功能分支上開發(fā)完成后，將 Feature 功能分支合并到 Develop 開發(fā)分支：

   

5. 1.0 版本所需的用戶登錄功能開發(fā)完畢，此時(shí) 1.0 版本的功能為可發(fā)布狀態(tài)，我們可以從 Develop 開發(fā)分支創(chuàng)建一個(gè)新的 Release 發(fā)布分支。在該分支上進(jìn)行最終測(cè)試和缺陷修復(fù)：

   

6. 在完成測(cè)試和修復(fù)后，將 Release 發(fā)布分支合并回 Main 主分支和 Develop 開發(fā)分支。同時(shí)，在 Main 主分支上打上標(biāo)簽Tag，以便追蹤版本：

   

7. 如果在生產(chǎn)環(huán)境中發(fā)現(xiàn)了緊急問題，可以直接從 Main 主分支上創(chuàng)建一個(gè) Hotfix 補(bǔ)丁分支，并進(jìn)行修復(fù)：

   

8. 當(dāng)問題成功解決后，將 Hotfix 補(bǔ)丁分支同步回 Main 主分支和 Develop 開發(fā)分支，以確保修復(fù)過的錯(cuò)誤能在當(dāng)前和未來的版本中得以修復(fù)。同時(shí)，在 Main 主分支上打上新的標(biāo)簽Tag：

   

9. 此時(shí)，在線支付功能開發(fā)完畢，將 Feature 功能分支合并回 Develop 開發(fā)分支：

   

10. 創(chuàng)建 Realse 發(fā)布分支準(zhǔn)備發(fā)布 2.0 版本：

    

11. 合并 Main 主分支，為 Main 主分支打上標(biāo)簽Tag 2.0.0，同時(shí)同步 Develop 開發(fā)分支:

    

12. 團(tuán)隊(duì)成員根據(jù)需要繼續(xù)創(chuàng)建新的功能分支、發(fā)布分支和補(bǔ)丁分支，推進(jìn)項(xiàng)目的開發(fā)和維護(hù)工作。文章來源地址http://www.zghlxwxcb.cn/news/detail-794317.html

到了這里，關(guān)于Gitflow：一種依據(jù) Git 構(gòu)建的分支管理工作流程模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！