git flow開發分支管理模型

Git Flow 是什麼

Git Flow是構建在Git之上的一個組織軟件開發活動的模型，是在Git之上構建的一項軟件開發最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行爲規範和簡化部分Git操做的工具。

2010年5月，在一篇名爲「一種成功的Git分支模型」的博文中，@nvie介紹了一種在Git之上的軟件開發模型。經過利用Git建立和管理分支的能力，爲每一個分支設定具備特定的含義名稱，並將軟件生命週期中的各種活動歸併到不一樣的分支上。實現了軟件開發過程不一樣操做的相互隔離。這種軟件開發的活動模型被nwie稱爲「Git Flow」。

通常而言，軟件開發模型有常見的瀑布模型、迭代開發模型、以及最近出現的敏捷開發模型等不一樣的模型。每種模型有各自應用場景。Git Flow重點解決的是因爲源代碼在開發過程當中的各類衝突致使開發活動混亂的問題。所以，Git flow能夠很好的於各類現有開發模型相結合使用。

在開始研究Git Flow的具體內容前，下面這張圖能夠看到模型的全貌（引自nvie的博文)：

Git Flow中的分支

Git Flow模型中定義了主分支和輔助分支兩類分支。

一、主分支用於組織與軟件開發、部署相關的活動。

主分支是全部開發活動的核心分支。全部的開發活動產生的輸出物最終都會反映到主分支的代碼中。

主分支分爲master分支和development分支。

1). master分支

master分支上存放的應該是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的
代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本號標籤（TAG）。

2). develop分支

develop分支是保存當前最新開發成果的分支。一般這個分支上的代碼也是可進行每日夜間發佈的代碼（Nightly build）。所以這個分支有時也能夠被稱做「integration branch」。

當develop分支上的代碼已實現了軟件需求說明書中全部的功能，經過了全部的測試後，而且代碼已經足夠穩定時，就能夠將全部的開發成果合併回master分支了。對於master分支上的新提交的代碼建議都打上一個新的版本號標籤（TAG），供後續代碼跟蹤使用。

所以，每次將develop分支上的代碼合併回master分支時，咱們均可以認爲一個新的可供在生產環境中部署的版本就產生了。一般而言，「僅在發佈新的可供部署的代碼時才更新master分支上的代碼」是推薦全部人都遵照的行爲準則。基於此，理論上說，每當有代碼提交到master分支時，咱們可使用Git Hook觸發軟件自動測試以及生產環境代碼的自動更新工做。這些自動化操做將有利於減小新代碼發佈以後的一些事務性工做。

二、輔助分支組織爲了解決特定的問題而進行的各類開發活動。

輔助分支是用於組織解決特定問題的各類軟件開發活動的分支。

輔助分支主要用於組織軟件新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發佈工做以及對生產代碼的缺陷進行緊急修復工做。這些分支與主分支不一樣，一般只會在有限的時間範圍內存在。

輔助分支分爲feature分支（開發新功能）、release分支（輔助版本發佈）和hotfix分支（修正生產代碼中的缺陷）。

以上這些分支都有固定的使用目的和分支操做限制。從單純技術的角度說，這些分支與Git其餘分支並無什麼區別，但經過命名，咱們定義了使用這些分支的方法。

1). feature分支

通常而言，feature分支代碼能夠保存在開發者本身的代碼庫中而不強制提交到主代碼庫裏。

使用規範：

(1).能夠從develop分支發起feature分支

(2).代碼必須合併回develop分支

(3).feature分支的命名可使用除master，develop，release-，hotfix-以外的任何名稱

(4).feature分支（有時也能夠被叫作「topic分支」）一般是在開發一項新的軟件功能的時候使用，這個分支上的代碼變動最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果很差的代碼變動）。

2). release分支

release分支是爲發佈新的產品版本而設計的。在這個分支上的代碼容許作小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等等）。經過在release分支上進行這些工做可讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。

當develop分支上的代碼已經包含了全部即將發佈的版本中所計劃包含的軟件功能，而且已經過全部測試時，咱們就能夠考慮準備建立release分支了。而全部在當前即將發佈的版本以外的業務需求必定要確保不能混到release分支以內（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，並被賦予版本號以後，develop分支就能夠爲「下一個版本」服務了。所謂的「下一個版本」是在當前即將發佈的版本以後發佈的版本。版本號的命名能夠依據項目定義的版本號命名規則進行。

使用規範：

(1).能夠從develop分支派生

(2).必須合併回develop分支和master分支

(3).分支命名慣例：release-*

3). hotfix分支

除了是計劃外建立的之外，hotfix分支與release分支十分類似：均可以產生一個新的可供在生產環境部署的軟件版本。

當生產環境中的軟件遇到了異常狀況或者發現了嚴重到必須當即修復的軟件缺陷的時候，就須要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工做。

這樣作的顯而易見的好處是不會打斷正在進行的develop分支的開發工做，可以讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工做。

使用規範：

(1).能夠從master分支派生

(2).必須合併回master分支和develop分支

(3).分支命名慣例：hotfix-*

Git Flow開發模型從源代碼管理角度對一般意義上的軟件開發活動進行了約束。應該說，爲咱們的軟件開發提供了一個可供參考的管理模型。Git Flow開發模型讓nvie的開發代碼倉庫保持整潔，讓小組各個成員之間的開發相互隔離，可以有效避免處於開發狀態中的代碼相互影響而致使的效率低下和混亂。

所謂模型，在不一樣的開發團隊，不一樣的文化，不一樣的項目背景狀況下都有可能須要進行適當的裁剪或擴充。