Git工做流指南：功能分支工做流（轉）

 

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

功能分支工做流背後的核心思路是全部的功能開發應該在一個專門的分支，而不是在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工做流是管理功能開發、發佈準備和維護的經常使用模式。

本文由 伯樂在線 - 李鼎 翻譯。未經許可，禁止轉載！   源文地址：http://blog.jobbole.com/76857/
英文出處：atlassian

譯註
本身理解粗淺，譯文源碼在GitHub上，翻譯中不足和不對之處，歡迎建議（提交Issue）和指正（Fork後提交代碼）！