通俗來講GitGFlow工作流就是在提交GIT的時候，master主分支主要是用來做發(fā)布版本來使用，平時開發(fā)會在develop版本代碼上進(jìn)行開發(fā)，最后等到要發(fā)布的時候，再merge合并到master主分支上。平時如果有需要創(chuàng)建新的功能分之，那么就在develpo分支的基礎(chǔ)上進(jìn)行創(chuàng)建，編輯完成之后再merge合并到develop分支上。

image.png

第一步為 master 分支配套一個 develop 分支。簡單來做可以本地創(chuàng)建一個空的 develop 分支，push 到服務(wù)器上

git branch develop
git push -u origin develop

以后這個分支將會包含了項(xiàng)目的全部歷史，而 master 分支將只包含了部分歷史。其它開發(fā)者這時應(yīng)該克隆中央倉庫，建好 develop 分支的跟蹤分支

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

image.png

這個示例中，小紅和小明開始各自的功能開發(fā)。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于 master 分支，而是應(yīng)該基于 develop 分支：

git checkout -b some-feature develop

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

git status
git add
git commit

image.png

添加了提交后，小紅覺得她的功能 OK 了。如果團(tuán)隊(duì)使用 Pull Requests，這時候可以發(fā)起一個用于合并到 develop 分支。否則她可以直接合并到她本地的 develop 分支后 push 到中央倉庫：

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

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

image.png

這個時候小明正在實(shí)現(xiàn)他的功能，小紅開始準(zhǔn)備她的第一個項(xiàng)目正式發(fā)布。像功能開發(fā)一樣，她用一個新的分支來做發(fā)布準(zhǔn)備。這一步也確定了發(fā)布的版本號：

git checkout -b release-0.1 develop

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

只要小紅創(chuàng)建這個分支并 push 到中央倉庫，這個發(fā)布就是功能凍結(jié)的。任何不在 develop 分支中的新功能都推到下個發(fā)布循環(huán)中。

image.png

一旦準(zhǔn)備好了對外發(fā)布，小紅合并修改到 master 分支和 develop 分支上，刪除發(fā)布分支。合并回 develop 分支很重要，因?yàn)樵诎l(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。另外，如果小紅的團(tuán)隊(duì)要求 Code Review，這是一個發(fā)起 Pull Request 的理想時機(jī)。

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

發(fā)布分支是作為功能開發(fā)（develop 分支）和對外發(fā)布（master 分支）間的緩沖。只要有合并到 master 分支，就應(yīng)該打好 Tag 以方便跟蹤。

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

Git 有提供各種勾子（hook），即倉庫有事件發(fā)生時觸發(fā)執(zhí)行的腳本?？梢耘渲靡粋€勾子，在你 push 中央倉庫的 master 分支時，自動構(gòu)建好對外發(fā)布。

image.png

對外發(fā)布后，小紅回去和小明一起做下個發(fā)布的新功能開發(fā)，直到有最終用戶開了一個 Ticket 抱怨當(dāng)前版本的一個 Bug。為了處理 Bug，小紅（或小明）從 master 分支上拉出了一個維護(hù)分支，提交修改以解決問題，然后直接合并回 master 分支：

git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

就像發(fā)布分支，維護(hù)分支中新加這些重要修改需要包含到 develop 分支中，所以小紅要執(zhí)行一個合并操作。然后就可以安全地刪除這個分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

到了這里，但愿你對集中式工作流、功能分支工作流和 GitFlow 工作流已經(jīng)感覺很舒適了。你應(yīng)該也牢固的掌握了本地倉庫的潛能，push/pull 模式和 Git 健壯的分支和合并模型。

記住，這里演示的工作流只是可能用法的例子，而不是在實(shí)際工作中使用 Git 不可違逆的條例。所以不要畏懼按自己需要對工作流的用法做取舍。不變的目標(biāo)就是讓 Git 為你所用。