git-flow流程規范

[TOC]

git flow是什么

GitFlow是構建在Git之上的一個組織軟件開發活動的模型，被譽為是在Git之上構建的一項軟件開發最佳實踐。
它定義了一個圍繞項目發布的嚴格分支模型。雖然比功能分支工作流復雜幾分，但提供了用于一個健壯的用于管理大型項目的框架。
 與feature branch workflow比起來，GitFlow沒有增加任何新的概念和命令，它只是一個git管理的規范，一個開發的指導方針。

為什么要推動使用git flow

雖然有這么優秀的版本管理工具，但是我們面對版本管理的時候，依然有非常大得挑戰，我們都知道大家工作在同一個倉庫上，那么彼此的代碼協作必然帶來很多問題和挑戰，如下：

• 如何開始一個Feature的開發，而不影響別的Feature？
• 由于很容易創建新分支，分支多了如何管理，時間久了，如何知道每個分支是干什么的？哪些分支已經合并回了主干？
• 如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在PrepareRelease的時候，開發人員可以繼續開發新的功能？
• 線上代碼出Bug了，如何快速修復？而且修復的代碼要包含到開發人員的分支以及下一個Release?
• 如何快速的找到每個上線的版本進行打包

大部分開發人員現在使用Git就只是用三個甚至兩個分支，一個是Master, 一個是Develop, 還有一個是基于Develop打得各種分支。這個在小項目規模的時候還勉強可以支撐，因為很多人做項目就只有一個Release, 但是人員一多，或者項目周期一長就會出現各種問題。

接下來我們來介紹規范下的分支

gitFlow常用分支

主分支

• 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分支是為發布新的產品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備發布版本所需的各項說明信息（版本號、發布時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代周期。
當develop分支上的代碼已經包含了所有即將發布的版本中所計劃包含的軟件功能，并且已通過所有測試時，我們就可以考慮準備創建release分支了。而所有在當前即將發布的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。
 成功的派生了release分支，并被賦予版本號之后，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將發布的版本之后發布的版本。版本號的命名可以依據項目定義的版本號命名規則進行。

• hotfix分支

使用規范：

• 可以從master分支派生

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

• 分支命名慣例：hotfix-*,hotfix/

  除了是計劃外創建的以外，hotfix分支與release分支十分相似：都可以產生一個新的可供在生產環境部署的軟件版本。 當生產環境中的軟件遇到了異常情況或者發現了嚴重到必須立即修復的軟件缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工作。 這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發工作，能夠讓團隊中負責新功能開發的人與負責代碼緊急修復的人并行的開展工作。 ### 更進一步

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

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

Practice

標準實踐是完全按照gitflow工作流的規范進行操作，上面也提到過，規范只是一個指導方針，真正如何使用還需要結合自己項目和團隊的風格進行改進，下面就是根據標準范式演化出來的一種工作流模式
如圖所示，我們開發的過程中按照版本迭代開啟一個新的release分支，這個分支將一直存在直到測試完成發布上線。但是其實并不在release上進行開發，而是在feature分支根據個人喜好進行開發，開發完成后再合并到release分支
而feature分支可以根據喜好分為按照功能創建，或者按照個人身份創建。如果一個功能比較大，或者說比較獨立，可以單獨開一個分支進行獨立開發。而如果另外一個人主要進行小修小改（在版本迭代過程中應該會經常遇到修復上一個版本的小問題，或者UI微調整），那就可以一直在自己專屬的分支進行開發工作。開發完成后再不斷的合并到release分支上
無論哪種開發模式，都應該謹記一點，就是要堅持勤push代碼，勤pull代碼

可能大家會發現這種開發模式會造成develop分支多余，我也覺得develop這個分支有點雞肋，暫時沒發現可以做什么，不過還是保留吧，誰知道哪天又需要了。

Git flow工具

git-flow 是一個 git 擴展集，是完全按照標準GitFlow工作流程封裝的一套git指令集合，用以幫助我們更方便的按照git-flow工作流程進行版本管理

安裝

• OS X

brew install git-flow

• Linux

apt-get install git-flow

• Windows

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

使用

• 初始化:git flow init
• 開始新Feature:git flow feature start MYFEATURE
• Publish一個Feature(也就是push到遠程):git flow feature publish MYFEATURE
• 獲取Publish的Feature:git flow feature pull origin MYFEATURE
• 完成一個Feature:git flow feature finish MYFEATURE
• 開始一個Release:git flow release start RELEASE [BASE]
• Publish一個Release:git flow release publish RELEASE
• 發布Release:git flow release finish RELEASE
  別忘了git push --tags
• 開始一個Hotfix:git flow hotfix start VERSION [BASENAME]
• 發布一個Hotfix:git flow hotfix finish VERSION