一旦你玩轉了集中式工作流，在開發過程中可以很簡單地加上功能分支，用來鼓勵開發者之間協作和簡化交流。
功能分支工作流背後的核心思路是所有的功能開發應該在一個專門的分支，而不是在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分支到中央倉庫。
倉庫管理的產品解決方案像Bitbucket或Stash，可以良好地支援Pull Requests。可以看看Stash的Pull Requests文件。
示例
下面的示例演示瞭如何把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工作流是管理功能開發、釋出準備和維護的常用模式。
譯註
自己理解粗淺，譯文原始碼在GitHub上，翻譯中不足和不對之處，歡迎建議（提交Issue）和指正（Fork後提交程式碼）！
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
