學習完整課程請移步 互聯網 Java 全棧工程師
本節視頻
概述
一旦你玩轉了集中式工作流，在開發過程中可以很簡單地加上功能分支，用來鼓勵開發者之間協作和簡化交流。
功能分支工作流背后的核心思路是所有的功能開發應該在一個專門的分支，而不是在 master 分支上。這個隔離可以方便多個開發者在各自的功能上開發而不會弄亂主干代碼。另外，也保證了 master 分支的代碼一定不會是有問題的，極大有利于集成環境。
功能開發隔離也讓 pull requests 工作流成功可能，pull requests 工作流能為每個分支發起一個討論，在分支合入正式項目之前，給其它開發者有表示贊同的機會。另外，如果你在功能開發中有問題卡住了，可以開一個 pull requests 來向同學們征求建議。這些做法的重點就是，pull requests 讓團隊成員之間互相評論工作變成非常方便！
工作方式
功能分支工作流仍然用中央倉庫，并且 master 分支還是代表了正式項目的歷史。但不是直接提交本地歷史到各自的本地 master 分支，開發者每次在開始新功能前先創建一個新分支。功能分支應該有個有描述性的名字，比如 animated-menu-items 或 issue-#1061，這樣可以讓分支有個清楚且高聚焦的用途。
在 master 分支和功能分支之間，Git 是沒有技術上的區別，所以開發者可以用和集中式工作流中完全一樣的方式編輯、暫存和提交修改到功能分支上。
另外，功能分支也可以（且應該）push 到中央倉庫中。這樣不修改正式代碼就可以和其它開發者分享提交的功能。由于 master 僅有的一個『特殊』分支，在中央倉庫上存多個功能分支不會有任何問題。當然，這樣做也可以很方便地備份各自的本地提交。
Pull Requests
功能分支除了可以隔離功能的開發，也使得通過 Pull Requests 討論變更成為可能。一旦某個開發完成一個功能，不是立即合并到 master，而是 push 到中央倉庫的功能分支上并發起一個 Pull Request 請求去合并修改到 master。在修改成為主干代碼前，這讓其它的開發者有機會先去 Review 變更。
Code Review 是 Pull Requests 的一個重要的收益，但 Pull Requests 目的是討論代碼一個通用方式。你可以把 Pull Requests 作為專門給某個分支的討論。這意味著可以在更早的開發過程中就可以進行 Code Review。比如，一個開發者開發功能需要幫助時，要做的就是發起一個 Pull Request，相關的人就會自動收到通知，在相關的提交旁邊能看到需要幫助解決的問題。
一旦 Pull Request 被接受了，發布功能要做的就和集中式工作流就很像了。首先，確定本地的 master 分支和上游的 master 分支是同步的。然后合并功能分支到本地 master 分支并 push 已經更新的本地 master 分支到中央倉庫。
示例
下面的示例演示了如何把 Pull Requests 作為 Code Review 的方式，但注意 Pull Requests 可以用于很多其它的目的。
小紅開始開發一個新功能
在開始開發功能前，小紅需要一個獨立的分支。使用下面的命令新建一個分支：
git checkout -b marys-feature master
這個命令檢出一個基于 master 名為 marys-feature 的分支，Git 的 -b 選項表示如果分支還不存在則新建分支。這個新分支上，小紅按老套路編輯、暫存和提交修改，按需要提交以實現功能：
git status
git add
git commit
小紅要去吃個午飯
早上小紅為新功能添加一些提交。去吃午飯前，push 功能分支到中央倉庫是很好的做法，這樣可以方便地備份，如果和其它開發協作，也讓他們可以看到小紅的提交。
git push -u origin marys-feature
這條命令 push marys-feature 分支到中央倉庫（origin），-u 選項設置本地分支去跟蹤遠程對應的分支。設置好跟蹤的分支后，小紅就可以使用 git push 命令省去指定推送分支的參數。
小紅完成功能開發
小紅吃完午飯回來，完成整個功能的開發。在合并到 master 之前，她發起一個 Pull Request 讓團隊的其它人知道功能已經完成。但首先，她要確認中央倉庫中已經有她最近的提交：
git push
然后，在她的 Git GUI 客戶端中發起 Pull Request，請求合并 marys-feature 到 master，團隊成員會自動收到通知。Pull Request 很酷的是可以在相關的提交旁邊顯示評注，所以你可以很對某個變更集提問。
小黑收到 Pull Request
小黑收到了 Pull Request 后會查看 marys-feature 的修改。決定在合并到正式項目前是否要做些修改，且通過 Pull Request 和小紅來回地討論。
小紅再做修改
要再做修改，小紅用和功能第一個迭代完全一樣的過程。編輯、暫存、提交并push更新到中央倉庫。小紅這些活動都會顯示在 Pull Request 上，小黑可以斷續做評注。
如果小黑有需要，也可以把 marys-feature 分支拉到本地，自己來修改，他加的提交也會一樣顯示在 Pull Request 上。
小紅發布她的功能
一旦小黑可以的接受 Pull Request，就可以合并功能到穩定項目代碼中（可以由小黑或是小紅來做這個操作）：
git checkout master
git pull
git pull origin marys-feature
git push
無論誰來做合并，首先要檢出 master 分支并確認是它是最新的。然后執行 git pull origin marys-feature 合并 marys-feature 分支到和已經和遠程一致的本地 master 分支。你可以使用簡單 git merge marys-feature 命令，但前面的命令可以保證總是最新的新功能分支。最后更新的 master 分支要重新 push 回到 origin。
這個過程常常會生成一個合并提交。有些開發者喜歡有合并提交，因為它像一個新功能和原來代碼基線的連通符。但如果你偏愛線性的提交歷史，可以在執行合并時 rebase 新功能到 master 分支的頂部，這樣生成一個快進（fast-forward）的合并。
一些 GUI 客戶端可以只要點一下『接受』按鈕執行好上面的命令來自動化 Pull Request 接受過程。如果你的不能這樣，至少在功能合并到 master 分支后能自動關閉 Pull Request。
與此同時，小明在做和小紅一樣的事
當小紅和小黑在 marys-feature 上工作并討論她的 Pull Request 的時候，小明在自己的功能分支上做完全一樣的事。
通過隔離功能到獨立的分支上，每個人都可以自主的工作，當然必要的時候在開發者之間分享變更還是比較繁瑣的。
總結
到了這里，但愿你發現了功能分支可以很直接地在集中式工作流的僅有的 master 分支上完成多功能的開發。另外，功能分支還使用了 Pull Request，使得可以在你的版本控制 GUI 客戶端中討論某個提交。
功能分支工作流是開發項目異常靈活的方式。問題是，有時候太靈活了。對于大型團隊，常常需要給不同分支分配一個更具體的角色。GitFlow 工作流是管理功能開發、發布準備和維護的常用模式。
