示例

下面的示例演示本工作流如何用于管理單個發(fā)布循環(huán)。假設(shè)你已經(jīng)創(chuàng)建了一個中央倉庫。

創(chuàng)建開發(fā)分支

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-release-cycle-5createdev.png" alt="git-workflow-release-cycle-5createdev" />

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

git branch develop
git push -u origin develop

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

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

現(xiàn)在每個開發(fā)都有了這些歷史分支的本地拷貝。

小紅和小明開始開發(fā)新功能

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-release-cycle-6maryjohnbeginnew.png" alt="git-workflow-release-cycle-6maryjohnbeginnew" />

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

git checkout -b some-feature develop

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

git status
git add <some-file>
git commit

小紅完成功能開發(fā)

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-release-cycle-7maryfinishes.png" alt="git-workflow-release-cycle-7maryfinishes" />

添加了提交后，小紅覺得她的功能OK了。如果團隊使用 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 分支是最新的。注意，功能決不應該直接合并到 master 分支。

沖突解決方法和集中式工作流一樣。

小紅開始準備發(fā)布

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-release-cycle-8maryprepsrelease.png" alt="git-workflow-release-cycle-8maryprepsrelease" />

這個時候小明正在實現(xiàn)他的功能，小紅開始準備她的第一個項目正式發(fā)布。

像功能開發(fā)一樣，她用一個新的分支來做發(fā)布準備。這一步也確定了發(fā)布的版本號：

git checkout -b release-0.1 develop

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

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

小紅完成發(fā)布

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-release-cycle-9maryfinishes.png" alt="git-workflow-release-cycle-9maryfinishes" />

一旦準備好了對外發(fā)布，小紅合并修改到 master 分支和 develop 分支上，刪除發(fā)布分支。合并回 develop 分支很重要，因為在發(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。

另外，如果小紅的團隊要求 Code Review ，這是一個發(fā)起 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

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

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

Git有提供各種勾子（ hook ），即倉庫有事件發(fā)生時觸發(fā)執(zhí)行的腳本。

可以配置一個勾子，在你 push 中央倉庫的 master 分支時，自動構(gòu)建好對外發(fā)布。

最終用戶發(fā)現(xiàn) Bug

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-gitflow-enduserbug.png" alt="git-workflow-gitflow-enduserbug" />

對外發(fā)布后，小紅回去和小明一起做下個發(fā)布的新功能開發(fā)，直到有最終用戶開了一個 Ticket 抱怨當前版本的一個 Bug 。

為了處理 Bug ，小紅（或小明）從 master 分支上拉出了一個維護分支，提交修改以解決問題，然后直接合并回 master 分支：

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

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

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

到了這里，但愿你對集中式工作流、功能分支工作流和 Gitflow 工作流已經(jīng)感覺很舒適了。

你應該也牢固的掌握了本地倉庫的潛能，push / pull 模式和 Git 健壯的分支和合并模型。

記住，這里演示的工作流只是可能用法的例子，而不是在實際工作中使用 Git 不可違逆的條例。

所以不要畏懼按自己需要對工作流的用法做取舍。不變的目標就是讓 Git 為你所用。