Git工作流指南：Pull Request工作流
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會有一些不同，但基本的過程是這樣的：
- 開發者在本地倉庫中新建一個專門的分支開發功能。
- 開發者
push分支修改到公開的Bitbucket倉庫中。 - 開發者通過
Bitbucket發起一個Pull Request。 - 團隊的其它成員
reviewcode，討論并修改。 - 項目維護者合并功能到官方倉庫中并關閉
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這些變更到自己的本地倉庫中。
下一站
到了這里，你應該有了所有需要的工具來集成Pull Request到你自己的工作流。請記住，Pull Request并不是為了替代任何基于Git的協作工作流，而是它們的一個便利的補充，讓團隊成員間的協作更輕松方便。