功能分支工做流

1.概述

一旦你玩轉了集中式工做流，在開發過程當中能夠很簡單地加上功能分支，用來鼓勵開發者之間協做和簡化交流。

功能分支工做流背後的核心思路是全部的功能開發應該在一個專門的分支，而不是在 master 分支上。這個隔離能夠方便多個開發者在各自的功能上開發而不會弄亂主幹代碼。另外，也保證了 master 分支的代碼必定不會是有問題的，極大有利於集成環境。

功能開發隔離也讓 pull requests 工做流成功可能，pull requests 工做流能爲每一個分支發起一個討論，在分支合入正式項目以前，給其它開發者有表示贊同的機會。另外，若是你在功能開發中有問題卡住了，能夠開一個 pull requests 來向同窗們徵求建議。這些作法的重點就是，pull requests 讓團隊成員之間互相評論工做變成很是方便！

2.工做方式

功能分支工做流仍然用中央倉庫，而且 master 分支仍是表明了正式項目的歷史。但不是直接提交本地歷史到各自的本地 master 分支，開發者每次在開始新功能前先建立一個新分支。功能分支應該有個有描述性的名字，好比 animated-menu-items 或 issue-#1061，這樣可讓分支有個清楚且高聚焦的用途。

在 master 分支和功能分支之間，Git 是沒有技術上的區別，因此開發者能夠用和集中式工做流中徹底同樣的方式編輯、暫存和提交修改到功能分支上。

另外，功能分支也能夠（且應該）push 到中央倉庫中。這樣不修改正式代碼就能夠和其它開發者分享提交的功能。因爲 master 僅有的一個『特殊』分支，在中央倉庫上存多個功能分支不會有任何問題。固然，這樣作也能夠很方便地備份各自的本地提交。

3.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 分支到中央倉庫。

4.示例

下面的示例演示瞭如何把 Pull Requests 做爲 Code Review 的方式，但注意 Pull Requests 能夠用於不少其它的目的。

1.小紅開始開發一個新功能

在開始開發功能前，小紅須要在本地一個獨立的分支。使用下面的命令新建一個分支：

git checkout -b marys-feature master   ///// 表示若是分支還不存在則新建分支-b

這個命令檢出一個基於 master 名爲 marys-feature 的分支，Git 的 -b 選項表示若是分支還不存在則新建分支。這個新分支上，小紅按老套路編輯、暫存和提交修改，按須要提交以實現功能：

git status
git add
git commit  將分支提交到遠程

 

2.小紅要去吃個午餐

早上小紅爲新功能添加一些提交。去吃午餐前，push 功能分支到中央倉庫是很好的作法，這樣能夠方便地備份，若是和其它開發協做，也讓他們能夠看到小紅的提交。

git push -u origin marys-featurev       ////  選項設置本地分支去跟蹤遠程-u

 

這條命令 push marys-feature 分支到中央倉庫（origin），-u 選項設置本地分支去跟蹤遠程對應的分支。設置好跟蹤的分支後，小紅就可使用 git push 命令省去指定推送分支的參數。

3.小紅完成功能開發

小紅吃完午餐回來，完成整個功能的開發。在合併到 master 以前，她發起一個 Pull Request 讓團隊的其它人知道功能已經完成。但首先，她要確認中央倉庫中已經有她最近的提交：

git push

 

而後，在她的 Git GUI 客戶端中發起 Pull Request，請求合併 marys-feature 到 master，團隊成員會自動收到通知。Pull Request 很酷的是能夠在相關的提交旁邊顯示評註，因此你能夠很對某個變動集提問。

4.小黑收到 Pull Request

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

5.小紅再作修改

要再作修改，小紅用和功能第一個迭代徹底同樣的過程。編輯、暫存、提交併push更新到中央倉庫。小紅這些活動都會顯示在 Pull Request 上，小黑能夠斷續作評註。

若是小黑有須要，也能夠把 marys-feature 分支拉到本地，本身來修改，他加的提交也會同樣顯示在 Pull Request 上。

6.小紅髮布她的功能

一旦小黑能夠的接受 Pull Request，就能夠合併功能到穩定項目代碼中（能夠由小黑或是小紅來作這個操做）：

git checkout master   -- 切換到本地master
git pull     -- 拉取最新master
git pull origin marys-feature   -- 拉取遠程某分支到本地master
git push    -- 推送到遠程master

 

不管誰來作合併，首先要檢出 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。

7.與此同時，小明在作和小紅同樣的事

當小紅和小黑在 marys-feature 上工做並討論她的 Pull Request 的時候，小明在本身的功能分支上作徹底同樣的事。

經過隔離功能到獨立的分支上，每一個人均可以自主的工做，固然必要的時候在開發者之間分享變動仍是比較繁瑣的。

5.總結

到了這裏，希望你發現了功能分支能夠很直接地在集中式工做流的僅有的 master 分支上完成多功能的開發。另外，功能分支還使用了 Pull Request，使得能夠在你的版本控制 GUI 客戶端中討論某個提交。

功能分支工做流是開發項目異常靈活的方式。問題是，有時候太靈活了。對於大型團隊，經常須要給不一樣分支分配一個更具體的角色。GitFlow 工做流是管理功能開發、發佈準備和維護的經常使用模式。