概述
GitFlow 工作流定義了一個圍繞項目發佈的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於一個健壯的用於管理大型項目的框架。
GitFlow 工作流沒有用超出功能分支工作流的概念和命令，而是爲不同的分支分配一個很明確的角色，並定義分支之間如何和什麼時候進行交互。除了使用功能分支，在做準備、維護和記錄發佈也使用各自的分支。當然你可以用上功能分支工作流所有的好處：Pull Requests、隔離實驗性開發和更高效的協作。
工作方式
GitFlow 工作流仍然用中央倉庫作爲所有開發者的交互中心。和其它的工作流一樣，開發者在本地工作並 push 分支到中央倉庫中。
歷史分支
相對使用僅有的一個 master 分支，GitFlow 工作流使用2個分支來記錄項目的歷史。master 分支存儲了正式發佈的歷史，而 develop 分支作爲功能的集成分支。這樣也方便 master 分支上的所有提交分配一個版本號。
剩下要說明的問題圍繞着這2個分支的區別展開。
功能分支
每個新功能位於一個自己的分支，這樣可以 push 到中央倉庫以備份和協作。但功能分支不是從 master 分支上拉出新分支，而是使用 develop 分支作爲父分支。當新功能完成時，合併回 develop 分支。新功能提交應該從不直接與 master 分支交互。
注意，從各種含義和目的上來看，功能分支加上 develop 分支就是功能分支工作流的用法。但 GitFlow 工作流沒有在這裏止步。
發佈分支
一旦 develop 分支上有了做一次發佈（或者說快到了既定的發佈日）的足夠功能，就從 develop 分支上 fork 一個發佈分支。新建的分支用於開始發佈循環，所以從這個時間點開始之後新的功能不能再加到這個分支上 —— 這個分支只應該做 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
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 分支時，自動構建好對外發布
最終用戶發現 Bug
對外發布後，小紅回去和小明一起做下個發佈的新功能開發，直到有最終用戶開了一個 Ticket 抱怨當前版本的一個 Bug。爲了處理 Bug，小紅（或小明）從 master 分支上拉出了一個維護分支，提交修改以解決問題，然後直接合並回 master 分支：
git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push
就像發佈分支，維護分支中新加這些重要修改需要包含到 develop 分支中，所以小紅要執行一個合併操作。然後就可以安全地刪除這個分支了：
git checkout develop
git merge issue-#001
git push
git branch -d issue-#001
總結
到了這裏，但願你對集中式工作流、功能分支工作流和 GitFlow 工作流已經感覺很舒適了。你應該也牢固的掌握了本地倉庫的潛能，push/pull 模式和 Git 健壯的分支和合並模型。
記住，這裏演示的工作流只是可能用法的例子，而不是在實際工作中使用 Git 不可違逆的條例。所以不要畏懼按自己需要對工作流的用法做取捨。不變的目標就是讓 Git 爲你所用。