Gitflow工作流

Gitflow工作流通過為功能開發、發布準備和維護分配獨立的分支，讓發布迭代過程更流暢。嚴格的分支模型也為大型項目提供了一些非常必要的結構。

這節介紹的Gitflow工作流借鑒自在nvie的Vincent Driessen。

Gitflow工作流定義了一個圍繞項目發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於一個健壯的用於管理大型項目的框架。

Gitflow工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個明確的角色，並定義分支之間如何和什麼時候進行交互。 除了使用功能分支，在做準備、維護和記錄發布時，也定義了各自的分支。 當然你可以用上功能分支工作流所有的好處：Pull Requests、隔離實驗性開發和更高效的協作。

Gitflow工作流仍然用中央倉庫作為所有開發者的交互中心。和其它的工作流一樣，開發者在本地工作並push分支到要中央倉庫中。

相對於使用僅有的一個master分支，Gitflow工作流使用兩個分支來記錄項目的歷史。master分支存儲了正式發布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號。

剩下要說明的問題圍繞著這2個分支的區別展開。

每個新功能位於一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合併回develop分支。 新功能提交應該從不直接與master分支交互。

注意，從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒有在這裡止步。

一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上checkout一個發布分支。 新建的分支用於開始發布循環，所以從這個時間點開始之後新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發布任務。 一旦對外發布的工作都完成了，發布分支合併到master分支並分配一個版本號打好Tag。 另外，這些從新建發布分支以來的做的修改要合併回develop分支。

使用一個用於發布準備的專門分支，使得一個團隊可以在完善當前的發布版本的同時，另一個團隊可以繼續開發下個版本的功能。 這也打造定義良好的開發階段（比如，可以很輕鬆地說，『這周我們要做準備發布版本4.0』，並且在倉庫的目錄結構中可以實際看到）。

常用的分支約定：

用於新建發布分支的分支: develop  用於合併的分支: master  分支命名: release-* 或 release/*  

維護分支或說是熱修復（hotfix）分支用於給產品發布版本（production releases）快速生成修補程式，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合併回master分支和develop分支（當前的發布分支），master分支應該用新的版本號打好Tag。

為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發布循環。 你可以把維護分支想成是一個直接在master分支上處理的臨時發布。

下面的示例演示本工作流如何用於管理單個發布循環。假設你已經創建了一個中央倉庫。

第一步為master分支配套一個develop分支。簡單來做可以本地創建一個空的develop分支，push到伺服器上：

git branch develop  git push -u origin develop  

以後這個分支將會包含了項目的全部歷史，而master分支將只包含了部分歷史。其它開發者這時應該克隆中央倉庫，建好develop分支的跟蹤分支：

git clone ssh://user@host/path/to/repo.git  git checkout -b develop origin/develop  

現在每個開發都有了這些歷史分支的本地拷貝。

這個示例中，小紅和小明開始各自的功能開發。他們需要為各自的功能創建相應的分支。新分支不是基於master分支，而是應該基於develop分支：

git checkout -b some-feature develop  

他們用老套路添加提交到各自功能分支上：編輯、暫存、提交：

git status  git add <some-file>  git commit  

添加了提交後，小紅覺得她的功能OK了。如果團隊使用Pull Requests，這時候可以發起一個用於合併到develop分支。 否則她可以直接合併到她本地的develop分支後push到中央倉庫：

git pull origin develop  git checkout develop  git merge some-feature  git push  git branch -d some-feature  

第一條命令在合併功能前確保develop分支是最新的。注意，功能決不應該直接合併到master分支。 衝突解決方法和集中式工作流一樣。

這個時候小明正在實現他的功能，小紅開始準備她的第一個項目正式發布。 像功能開發一樣，她用一個新的分支來做發布準備。這一步也確定了發布的版本號：

git checkout -b release-0.1 develop  

這個分支是清理髮布、執行所有測試、更新文檔和其它為下個發布做準備操作的地方，像是一個專門用於改善發布的功能分支。

只要小紅創建這個分支並push到中央倉庫，這個發布就是功能凍結的。任何不在develop分支中的新功能都推到下個發布循環中。

一旦準備好了對外發布，小紅合併修改到master分支和develop分支上，刪除發布分支。合併回develop分支很重要，因為在發布分支中已經提交的更新需要在後面的新功能中也要是可用的。 另外，如果小紅的團隊要求Code Review，這是一個發起Pull Request的理想時機。

git checkout master  git merge release-0.1  git push  git checkout develop  git merge release-0.1  git push  git branch -d release-0.1  

發布分支是作為功能開發（develop分支）和對外發布（master分支）間的緩衝。只要有合併到master分支，就應該打好Tag以方便跟蹤。

git tag -a 0.1 -m "Initial public release" master  git push --tags  

Git有提供各種勾子（hook），即倉庫有事件發生時觸發執行的腳本。 可以配置一個勾子，在你push中央倉庫的master分支時，自動構建好版本，並對外發布。