學習完整課程請移步 互聯網 Java 全棧工程師

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。

工作方式

Pull Request 可以和功能分支工作流、GitFlow 工作流或 Forking 工作流一起使用。但 Pull Request 要求要么分支不同，要么倉庫不同，所以不能用于集中式工作流。在不同的工作流中使用 Pull Request 會有一些不同，但基本的過程是這樣的：

• 開發者在本地倉庫中新建一個專門的分支開發功能。
• 開發者 push 分支修改到公開的 Bitbucket 倉庫中。
• 開發者通過 Bitbucket 發起一個 Pull Request。
• 團隊的其它成員 review code，討論并修改。
• 項目維護者合并功能到官方倉庫中并關閉 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 這些變更到自己的本地倉庫中。

總結

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