Git Flow-基於git的原始程式碼控制模型

標籤：

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分支。

master分支

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

develop分支

develop分支是儲存當前最新開發成果的分支。通常這個分支上的代碼也是可進行每日夜間發布的代碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。

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

因此，每次將develop分支上的代碼合并回master分支時，我們都可以認為一個新的可供在生產環境中部署的版本就產生了。通常而言，“僅在發布新的可供部署的代碼時才更新master分支上的代碼”是推薦所有人都遵守的管理辦法。基於此，理論上說，每當有代碼提交到master分支時，我們可以使用Git Hook觸發軟體自動化的測試以及生產環境代碼的自動更新工作。這些自動化操作將有利於減少新代碼發布之後的一些事務性工作。

輔助分支

輔助分支是用於組織解決特定問題的各種軟體開發活動的分支。輔助分支主要用於組織軟體新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發布工作以及對生產代碼的缺陷進行緊急修複工作。這些分支與主分支不同，通常只會在有限的時間範圍記憶體在。

輔助分支包括：

• 用於開發新功能時所使用的feature分支；

• 用於輔助版本發布的release分支；

• 用於修正生產代碼中的缺陷的hotfix分支。

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

feature分支

使用規範：

• 可以從develop分支發起feature分支

• 代碼必須合并回develop分支

• feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱

feature分支（有時也可以被叫做“topic分支”）通常是在開發一項新的軟體功能的時候使用，這個分支上的代碼變更最終合并回develop分支或者乾脆被拋棄掉（例如實驗性且效果不好的代碼變更）。

一般而言，feature分支代碼可以儲存在開發人員自己的程式碼程式庫中而不強制提交到主程式碼程式庫裡。

release分支

使用規範：

• 可以從develop分支派生

• 必須合并回develop分支和master分支

• 分支命名慣例：release-*

release分支是為發布新的產品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備發布版本所需的各項說明資訊（版本號碼、發布時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交，進入新的軟體開發迭代周期。

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

成功的派生了release分支，並被賦予版本號碼之後，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將發布的版本之後發布的版本。版本號碼的命名可以依據項目定義的版本號碼命名規則進行。

hotfix分支

使用規範：

• 可以從master分支派生

• 必須合并回master分支和develop分支

• 分支命名慣例：hotfix-*

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

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

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

更進一步

Git Flow開發模型從原始程式碼控制角度對通常意義上的軟體開發活動進行了約束。應該說，為我們的軟體開發提供了一個可供參考的管理模型。Git Flow開發模型讓nvie的開發代碼倉庫保持整潔，讓小組各個成員之間的開發相互隔離，能夠有效避免處於開發狀態中的代碼相互影響而導致的效率低下和混亂。

所謂模型，在不同的Team Dev，不同的文化，不同的項目背景情況下都有可能需要進行適當的裁剪或擴充。祝各位好運！

PS：為了簡化使用Git Flow模型時Git指令的複雜性，nvie開發出了一套git增強指令集。可以運行於Windows、Linux、Unix和Mac作業系統之下。有興趣的同學可以去看看。

附錄安裝Git Flow

Git Flow的在不同的作業系統之下有一些輕微的不同。好在nvie給出了詳細的指導。

Windows

配合Cygwin使用。Cygwin之下的安裝非常簡單。執行如下指令即可：

wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

使用這條命令在大多數情況下都可以完成Git Flow的安裝。但在少數情況下也會遇到異常：

• 執行 git flow init 命令後出現錯誤："flags: FATAL unable to determine getopt version"

  需要使用Cygwin的Util-linux安裝包。重新使用cywgin的setup安裝吧。

• 如果出現類似"$‘\r‘: command not found"的錯誤，則可能是分行符號出現了問題。可以使用sed命令來快速解決。

$ sed -i ‘s/\n\r/\n/mg‘ /usr/local/bin/git-flow*$ sed -i ‘s/\n\r/\n/mg‘ /usr/local/bin/gitflow-*

轉載至圖靈社區，作者:麥滿屯 

Git Flow-基於git的原始程式碼控制模型