示例

下面的示例演示了如何把 Pull Requests 作為 Code Review 的方式，但注意 Pull Requests 可以用于很多其它的目的。

小紅開始開發(fā)一個新功能

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-2.png" alt="" />

在開始開發(fā)功能前，小紅需要一個獨立的分支。使用下面的命令新建一個分支：

git checkout -b marys-feature master

這個命令檢出一個基于 master 名為 marys-feature 的分支， Git 的 -b 選項表示如果分支還不存在則新建分支。 這個新分支上，小紅按老套路編輯、暫存和提交修改，按需要提交以實現(xiàn)功能：

git status
git add <some-file>
git commit

小紅要去吃個午飯

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-3.png" alt="" />

早上小紅為新功能添加一些提交。 去吃午飯前，push 功能分支到中央倉庫是很好的做法，這樣可以方便地備份，如果和其它開發(fā)協(xié)作，也讓他們可以看到小紅的提交。

git push -u origin marys-feature

這條命令 push marys-feature 分支到中央倉庫（ origin ），-u 選項設(shè)置本地分支去跟蹤遠(yuǎn)程對應(yīng)的分支。 設(shè)置好跟蹤的分支后，小紅就可以使用 git push 命令省去指定推送分支的參數(shù)。

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

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-4.png" alt="" />

小紅吃完午飯回來，完成整個功能的開發(fā)。在合并到 master 之前， 她發(fā)起一個 Pull Request 讓團隊的其它人知道功能已經(jīng)完成。但首先，她要確認(rèn)中央倉庫中已經(jīng)有她最近的提交：

git push

然后，在她的 Git GUI 客戶端中發(fā)起 Pull Request ，請求合并 marys-feature 到 master ，團隊成員會自動收到通知。 Pull Request 很酷的是可以在相關(guān)的提交旁邊顯示評注，所以你可以對某個變更集提問。

小黑收到 Pull Request

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-5.png" alt="" />

小黑收到了 Pull Request 后會查看 marys-feature 的修改。決定在合并到正式項目前是否要做些修改，且通過 Pull Request 和小紅來回地討論。

小紅再做修改

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-6.png" alt="" />

要再做修改，小紅用和功能第一個迭代完全一樣的過程。編輯、暫存、提交并 push 更新到中央倉庫。小紅這些活動都會顯示在 Pull Request 上，小黑可以斷續(xù)做評注。

如果小黑有需要，也可以把 marys-feature 分支拉到本地，自己來修改，他加的提交也會一樣顯示在 Pull Request 上。

小紅發(fā)布她的功能

http://wiki.jikexueyuan.com/project/git-workflow-tutorial/images/git-workflow-feature-branch-7.png" alt="" />

一旦小黑可以的接受 Pull Request ，就可以合并功能到穩(wěn)定項目代碼中（可以由小黑或是小紅來做這個操作）：

git checkout master
git pull
git pull origin marys-feature
git push

無論誰來做合并，首先要檢出 master 分支并確認(rèn)是它是最新的。然后執(zhí)行 git pull origin marys-feature 合并 marys-feature 分支到和已經(jīng)和遠(yuǎn)程一致的本地 master 分支。 你可以使用簡單 git merge marys-feature 命令，但前面的命令可以保證總是最新的新功能分支。 最后更新的 master 分支要重新 push 回到 origin 。

這個過程常常會生成一個合并提交。有些開發(fā)者喜歡有合并提交，因為它像一個新功能和原來代碼基線的連通符。 但如果你偏愛線性的提交歷史，可以在執(zhí)行合并時 rebase 新功能到 master 分支的頂部，這樣生成一個快進(jìn)（ fast-forward ）的合并。

一些 GUI 客戶端可以只要點一下『接受』按鈕執(zhí)行好上面的命令來自動化 Pull Request 接受過程。 如果你的不能這樣，至少在功能合并到 master 分支后能自動關(guān)閉 Pull Request 。

與此同時，小明在做和小紅一樣的事

當(dāng)小紅和小黑在 marys-feature 上工作并討論她的 Pull Request 的時候，小明在自己的功能分支上做完全一樣的事。

通過隔離功能到獨立的分支上，每個人都可以自主的工作，當(dāng)然必要的時候在開發(fā)者之間分享變更還是比較繁瑣的。

到了這里，但愿你發(fā)現(xiàn)了功能分支可以很直接地在 集中式工作流 的僅有的 master 分支上完成多功能的開發(fā)。 另外，功能分支還使用了 Pull Request ，使得可以在你的版本控制 GUI 客戶端中討論某個提交。

功能分支工作流是開發(fā)項目異常靈活的方式。問題是，有時候太靈活了。對于大型團隊，常常需要給不同分支分配一個更具體的角色。 Gitflow 工作流是管理功能開發(fā)、發(fā)布準(zhǔn)備和維護的常用模式。