學習完整課程請移步 互聯網 Java 全棧工程師
本節視頻
概述
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 為你所用。
