Git工做流指南：Pull Request工做流

參考地址：http://blog.jobbole.com/76854/

 

Pull Requests是Bitbucket上方便開發者之間協做的功能。提供了一個用戶友好的Web界面，在集成提交的變動到正式項目前能夠對變動進行討論。

開發者向團隊成員通知功能開發已經完成，Pull Requests是最簡單的用法。開發者完成功能開發後，經過Bitbucket帳號發起一個Pull Request。這樣讓涉及這個功能的全部人知道，要去作Code Review和合併到master分支。

可是，Pull Request遠不止一個簡單的通知，而是爲討論提交的功能的一個專門論壇。若是變動有任何問題，團隊成員反饋在Pull Request中，甚至push新的提交微調功能。全部的這些活動都直接跟蹤在Pull Request中。

相比其它的協做模型，這種分享提交的形式有助於打造一個更流暢的工做流。SVN和Git都能經過一個簡單的腳本收到通知郵件；可是，討論變動時，開發者一般只能去回覆郵件。這樣作會變得雜亂，尤爲還要涉及後面的幾個提交時。Pull Requests把全部相關功能整合到一個和Bitbucket倉庫界面集成的用戶友好Web界面中。

解析Pull Request

當要發起一個Pull Request，你所要作的就是請求（Request）另外一個開發者（好比項目的維護者），來pull你倉庫中一個分支到他的倉庫中。這意味着你要提供4個信息（源倉庫、源分支、目的倉庫、目的分支），以發起Pull Request。

這些值多數Bitbucket都會設置上合適的缺省值。但取決你用的協做工做流，你的團隊可能會要指定不一樣的值。上圖顯示了一個Pull Request請求合併一個功能分支到正式的master分支上，但能夠有多種不一樣的Pull Request用法。

工做方式

Pull Request能夠和功能分支工做流、Gitflow工做流或Forking工做流一塊兒使用。但Pull Request要求要麼分支不一樣，要麼倉庫不一樣，因此不能用於集中式工做流。在不一樣的工做流中使用Pull Request會有一些不一樣，但基本的過程是這樣的：

1. 開發者在本地倉庫中新建一個專門的分支開發功能。
2. 開發者push分支修改到公開的Bitbucket倉庫中。
3. 開發者經過Bitbucket發起一個Pull Request。
4. 團隊的其它成員review code，討論並修改。
5. 項目維護者合併功能到官方倉庫中並關閉Pull Request。

本文後面內容說明，Pull Request在不一樣協做工做流中如何應用。

在功能分支工做流中使用Pull Request

功能分支工做流用一個共享的Bitbucket倉庫來管理協做，開發者在專門的分支上開發功能。但不是當即合併到master分支上，而是在合併到主代碼庫以前開發者應該開一個Pull Request發起功能的討論。

功能分支工做流只有一個公開的倉庫，因此Pull Request的目的倉庫和源倉庫老是同一個。一般開發者會指定他的功能分支做爲源分支，master分支做爲目的分支。

收到Pull Request後，項目維護者要決定如何作。若是功能沒問題，就簡單地合併到master分支，關閉Pull Request。但若是提交的變動有問題，他能夠在Pull Request中反饋。以後新加的提交也會評論以後接着顯示出來。

在功能尚未徹底開發完的時候，也可能發起一個Pull Request。好比開發者在實現某個需求時碰到了麻煩，他能夠發一個包含正在進行中工做的Pull Request。其它的開發者能夠在Pull Request提供建議，或者甚至直接添加提交來解決問題。

在Gitflow工做流中使用Pull Request

Gitflow工做流和功能分支工做流相似，但圍繞項目發佈定義一個嚴格的分支模型。在Gitflow工做流中使用Pull Request讓開發者在發佈分支或是維護分支上工做時，能夠有個方便的地方對關於發佈分支或是維護分支的問題進行交流。

Gitflow工做流中Pull Request的使用過程和上一節中徹底一致：當一個功能、發佈或是熱修復分支須要Review時，開發者簡單發起一個Pull Request，團隊的其它成員會經過Bitbucket收到通知。

新功能通常合併到develop分支，而發佈和熱修復則要同時合併到develop分支和master分支上。Pull Request可能用作全部合併的正式管理。

在Forking工做流中使用Pull Request

在Forking工做流中，開發者push完成的功能到他本身的倉庫中，而不是共享倉庫。而後，他發起一個Pull Request，讓項目維護者知道他的功能已經能夠Review了。

在這個工做流，Pull Request的通知功能很是有用，由於項目維護者不可能知道其它開發者在他們本身的倉庫添加了提交。

因爲各個開發有本身的公開倉庫，Pull Request的源倉庫和目標倉庫不是同一個。源倉庫是開發者的公開倉庫，源分支是包含了修改的分支。若是開發者要合併修改到正式代碼庫中，那麼目標倉庫是正式倉庫，目標分支是master分支。

Pull Request也能夠用於正式項目以外的其它開發者之間的協做。好比，若是一個開發者和一個團隊成員一塊兒開發一個功能，他們能夠發起一個Pull Request，用團隊成員的Bitbucket倉庫做爲目標，而不是正式項目的倉庫。而後使用相同的功能分支做爲源和目標分支。

2個開發者之間能夠在Pull Request中討論和開發功能。完成開發後，他們能夠發起另外一個Pull Request，請求合併功能到正式的master分支。在Forking工做流中，這樣的靈活性讓Pull Request成爲一個強有力的協做工具。

示例

下面的示例演示了Pull Request如何在在Forking工做流中使用。也一樣適用於小團隊的開發協做和第三方開發者向開源項目的貢獻。

在示例中，小紅是個開發，小明是項目維護者。他們各自有一個公開的Bitbucket倉庫，而小明的倉庫包含了正式工程。

小紅fork正式項目

小紅先要fork小明的Bitbucket倉庫，開始項目的開發。她登錄Bitbucket，瀏覽到小明的倉庫頁面，
點Fork按鈕。

而後爲fork出來的倉庫填寫名字和描述，這樣小紅就有了服務端的項目拷貝了。

小紅克隆她的Bitbucket倉庫

下一步，小紅克隆本身剛纔fork出來的Bitbucket倉庫，以在本機上準備出工做拷貝。命令以下：

git clone https://user@bitbucket.org/user/repo.git

請記住，git clone會自動建立origin遠程別名，是指向小紅fork出來的倉庫。

小紅開發新功能

在開始改代碼前，小紅要爲新功能先新建一個新分支。她會用這個分支做爲Pull Request的源分支。


git checkout -b some-feature

編輯代碼

git commit -a -m "Add first draft of some feature"


在新功能分支上，小紅按須要添加提交。甚至若是小紅以爲功能分支上的提交歷史太亂了，她能夠用交互式rebase來刪除或壓制提交。對於大型項目，整理功能分支的歷史可讓項目維護者更容易看出在Pull Request中作了什麼內容。

小紅push功能到她的Bitbucket倉庫中

小紅完成了功能後，push功能到她本身的Bitbucket倉庫中（不是正式倉庫），用下面簡單的命令：

git push origin some-branch

這時她的變動可讓項目維護者看到了（或者任何想要看的協做者）。

小紅髮起Pull Request

Bitbucket上有了她的功能分支後，小紅能夠用她的Bitbucket帳號瀏覽到她的fork出來的倉庫頁面，點右上角的【Pull Request】按鈕，發起一個Pull Request。彈出的表單自動設置小紅的倉庫爲源倉庫，詢問小紅以指定源分支、目標倉庫和目標分支。

小紅想要合併功能到正式倉庫，因此源分支是她的功能分支，目標倉庫是小明的公開倉庫，而目標分支是master分支。另外，小紅須要提供Pull Request的標題和描述信息。若是須要小明之外的人審覈批准代碼，她能夠把這些人填在【Reviewers】文本框中。

建立好了Pull Request，通知會經過Bitbucket系統消息或郵件（可選）發給小明。

小明review Pull Request

在小明的Bitbucket倉庫頁面的【Pull Request】Tab能夠看到全部人發起的Pull Request。點擊小紅的Pull Request會顯示出Pull Request的描述、功能的提交歷史和每一個變動的差別（diff）。

若是小明想要合併到項目中，只要點一下【Merge】按鈕，就能夠贊成Pull Request併合併到master分支。

但若是像這個示例中同樣小明發現了在小紅的代碼中的一個小Bug，要小紅在合併前修復。小明能夠在整個Pull Request上加上評註，或是選擇歷史中的某個提交加上評註。

小紅補加提交

若是小紅對反饋有任何疑問，能夠在Pull Request中響應，把Pull Request看成是她功能討論的論壇。

小紅在她的功能分支新加提交以解決代碼問題，並push到她的Bitbucket倉庫中，就像前一輪中的作法同樣。這些提交會進入的Pull Request，小明在原來的評註旁邊能夠再次review變動。

小明接受Pull Request

最終，小明接受變動，合併功能分支到master分支，並關閉Pull Request。至此，功能集成到項目中，其它的項目開發者能夠用標準的git pull命令pull這些變動到本身的本地倉庫中。