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://[email protected]/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這些變更到自己的本地倉庫中。

下一站

到了這裡，你應該有了所有需要的工具來整合Pull Request到你自己的工作流。請記住，Pull Request並不是為了替代任何基於Git的協作工作流，而是它們的一個便利的補充，讓團隊成員間的協作更輕鬆方便。