Pull Requests是Bitbucket上方便開發(fā)者之間協(xié)作的功能胎撤。提供了一個(gè)用戶友好的Web界面袄友，在集成提交的變更到正式項(xiàng)目前可以對變更進(jìn)行討論欧啤。

image.png

開發(fā)者向團(tuán)隊(duì)成員通知功能開發(fā)已經(jīng)完成，Pull Requests是最簡單的用法绽慈。開發(fā)者完成功能開發(fā)后薛训，通過Bitbucket賬號發(fā)起一個(gè)Pull Request媒吗。這樣讓涉及這個(gè)功能的所有人知道，要去做Code Review和合并到master分支乙埃。

但是闸英，Pull Request遠(yuǎn)不止一個(gè)簡單的通知，而是為討論提交的功能的一個(gè)專門論壇介袜。如果變更有任何問題甫何，團(tuán)隊(duì)成員反饋在Pull Request中，甚至push新的提交微調(diào)功能遇伞。所有的這些活動(dòng)都直接跟蹤在Pull Request中辙喂。

image.png

相比其它的協(xié)作模型，這種分享提交的形式有助于打造一個(gè)更流暢的工作流鸠珠。SVN和Git都能通過一個(gè)簡單的腳本收到通知郵件巍耗；但是，討論變更時(shí)渐排，開發(fā)者通常只能去回復(fù)郵件炬太。這樣做會(huì)變得雜亂，尤其還要涉及后面的幾個(gè)提交時(shí)飞盆。Pull Requests把所有相關(guān)功能整合到一個(gè)和Bitbucket倉庫界面集成的用戶友好Web界面中娄琉。

解析Pull Request

當(dāng)要發(fā)起一個(gè)Pull Request次乓，你所要做的就是請求（Request）另一個(gè)開發(fā)者（比如項(xiàng)目的維護(hù)者）吓歇，來pull你倉庫中一個(gè)分支到他的倉庫中。這意味著你要提供4個(gè)信息（源倉庫票腰、源分支城看、目的倉庫、目的分支）杏慰，以發(fā)起Pull Request测柠。

image.png

這些值多數(shù)Bitbucket都會(huì)設(shè)置上合適的缺省值炼鞠。但取決你用的協(xié)作工作流，你的團(tuán)隊(duì)可能會(huì)要指定不同的值轰胁。上圖顯示了一個(gè)Pull Request請求合并一個(gè)功能分支到正式的master分支上谒主，但可以有多種不同的Pull Request用法。

工作方式

Pull Request可以和功能分支工作流赃阀、Gitflow工作流或Forking工作流一起使用霎肯。但Pull Request要求要么分支不同，要么倉庫不同榛斯，所以不能用于集中式工作流观游。在不同的工作流中使用Pull Request會(huì)有一些不同，但基本的過程是這樣的：

1. 開發(fā)者在本地倉庫中新建一個(gè)專門的分支開發(fā)功能驮俗。

2. 開發(fā)者push分支修改到公開的Bitbucket倉庫中懂缕。

3. 開發(fā)者通過Bitbucket發(fā)起一個(gè)Pull Request。

4. 團(tuán)隊(duì)的其它成員review

   code王凑，討論并修改搪柑。

5. 項(xiàng)目維護(hù)者合并功能到官方倉庫中并關(guān)閉Pull Request。

本文后面內(nèi)容說明荤崇，Pull Request在不同協(xié)作工作流中如何應(yīng)用拌屏。

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

功能分支工作流用一個(gè)共享的Bitbucket倉庫來管理協(xié)作，開發(fā)者在專門的分支上開發(fā)功能术荤。但不是立即合并到master分支上倚喂，而是在合并到主代碼庫之前開發(fā)者應(yīng)該開一個(gè)Pull Request發(fā)起功能的討論。

image.png

功能分支工作流只有一個(gè)公開的倉庫瓣戚，所以Pull Request的目的倉庫和源倉庫總是同一個(gè)端圈。通常開發(fā)者會(huì)指定他的功能分支作為源分支，master分支作為目的分支子库。

收到Pull Request后舱权，項(xiàng)目維護(hù)者要決定如何做。如果功能沒問題仑嗅，就簡單地合并到master分支宴倍，關(guān)閉Pull Request。但如果提交的變更有問題仓技，他可以在Pull Request中反饋鸵贬。之后新加的提交也會(huì)評論之后接著顯示出來。

在功能還沒有完全開發(fā)完的時(shí)候脖捻，也可能發(fā)起一個(gè)Pull Request阔逼。比如開發(fā)者在實(shí)現(xiàn)某個(gè)需求時(shí)碰到了麻煩，他可以發(fā)一個(gè)包含正在進(jìn)行中工作的Pull Request地沮。其它的開發(fā)者可以在Pull Request提供建議嗜浮，或者甚至直接添加提交來解決問題羡亩。

在Gitflow工作流中使用Pull Request

Gitflow工作流和功能分支工作流類似，但圍繞項(xiàng)目發(fā)布定義一個(gè)嚴(yán)格的分支模型危融。在Gitflow工作流中使用Pull Request讓開發(fā)者在發(fā)布分支或是維護(hù)分支上工作時(shí)畏铆，可以有個(gè)方便的地方對關(guān)于發(fā)布分支或是維護(hù)分支的問題進(jìn)行交流。

image.png

Gitflow工作流中Pull Request的使用過程和上一節(jié)中完全一致：當(dāng)一個(gè)功能吉殃、發(fā)布或是熱修復(fù)分支需要Review時(shí)及志，開發(fā)者簡單發(fā)起一個(gè)Pull Request，團(tuán)隊(duì)的其它成員會(huì)通過Bitbucket收到通知寨腔。

新功能一般合并到develop分支速侈，而發(fā)布和熱修復(fù)則要同時(shí)合并到develop分支和master分支上。Pull Request可能用做所有合并的正式管理迫卢。

在Forking工作流中使用Pull Request

在Forking工作流中倚搬，開發(fā)者push完成的功能到他自己的倉庫中，而不是共享倉庫乾蛤。然后每界，他發(fā)起一個(gè)Pull Request，讓項(xiàng)目維護(hù)者知道他的功能已經(jīng)可以Review了家卖。

在這個(gè)工作流眨层，Pull Request的通知功能非常有用，因?yàn)轫?xiàng)目維護(hù)者不可能知道其它開發(fā)者在他們自己的倉庫添加了提交上荡。

image.png

由于各個(gè)開發(fā)有自己的公開倉庫趴樱，Pull Request的源倉庫和目標(biāo)倉庫不是同一個(gè)。源倉庫是開發(fā)者的公開倉庫酪捡，源分支是包含了修改的分支叁征。如果開發(fā)者要合并修改到正式代碼庫中，那么目標(biāo)倉庫是正式倉庫逛薇，目標(biāo)分支是master分支捺疼。

Pull Request也可以用于正式項(xiàng)目之外的其它開發(fā)者之間的協(xié)作。比如永罚，如果一個(gè)開發(fā)者和一個(gè)團(tuán)隊(duì)成員一起開發(fā)一個(gè)功能啤呼，他們可以發(fā)起一個(gè)Pull Request，用團(tuán)隊(duì)成員的Bitbucket倉庫作為目標(biāo)呢袱，而不是正式項(xiàng)目的倉庫官扣。然后使用相同的功能分支作為源和目標(biāo)分支。

image.png

2個(gè)開發(fā)者之間可以在Pull Request中討論和開發(fā)功能产捞。完成開發(fā)后醇锚，他們可以發(fā)起另一個(gè)Pull Request哼御，請求合并功能到正式的master分支坯临。在Forking工作流中焊唬，這樣的靈活性讓Pull Request成為一個(gè)強(qiáng)有力的協(xié)作工具。

示例

下面的示例演示了Pull Request如何在在Forking工作流中使用看靠。也同樣適用于小團(tuán)隊(duì)的開發(fā)協(xié)作和第三方開發(fā)者向開源項(xiàng)目的貢獻(xiàn)赶促。

在示例中，小紅是個(gè)開發(fā)挟炬，小明是項(xiàng)目維護(hù)者鸥滨。他們各自有一個(gè)公開的Bitbucket倉庫，而小明的倉庫包含了正式工程谤祖。

小紅fork正式項(xiàng)目

image.png

小紅先要fork小明的Bitbucket倉庫婿滓，開始項(xiàng)目的開發(fā)。她登陸Bitbucket粥喜，瀏覽到小明的倉庫頁面凸主，
點(diǎn)Fork按鈕。

image.png

然后為fork出來的倉庫填寫名字和描述额湘，這樣小紅就有了服務(wù)端的項(xiàng)目拷貝了卿吐。

小紅克隆她的Bitbucket倉庫

image.png

下一步，小紅克隆自己剛才fork出來的Bitbucket倉庫锋华，以在本機(jī)上準(zhǔn)備出工作拷貝嗡官。命令如下：

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

請記住，git clone會(huì)自動(dòng)創(chuàng)建origin遠(yuǎn)程別名毯焕，是指向小紅fork出來的倉庫衍腥。

小紅開發(fā)新功能

image.png

在開始改代碼前，小紅要為新功能先新建一個(gè)新分支纳猫。她會(huì)用這個(gè)分支作為Pull Request的源分支紧阔。

git checkout -b some-feature

# 編輯代碼

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

在新功能分支上，小紅按需要添加提交续担。甚至如果小紅覺得功能分支上的提交歷史太亂了擅耽，她可以用交互式rebase來刪除或壓制提交。對于大型項(xiàng)目物遇，整理功能分支的歷史可以讓項(xiàng)目維護(hù)者更容易看出在Pull Request中做了什么內(nèi)容乖仇。

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

image.png

小紅完成了功能后，push功能到她自己的Bitbucket倉庫中（不是正式倉庫）询兴，用下面簡單的命令：

git push origin some-branch

這時(shí)她的變更可以讓項(xiàng)目維護(hù)者看到了（或者任何想要看的協(xié)作者）乃沙。

小紅發(fā)起Pull Request

image.png

Bitbucket上有了她的功能分支后，小紅可以用她的Bitbucket賬號瀏覽到她的fork出來的倉庫頁面诗舰，點(diǎn)右上角的【Pull Request】按鈕警儒，發(fā)起一個(gè)Pull Request。彈出的表單自動(dòng)設(shè)置小紅的倉庫為源倉庫，詢問小紅以指定源分支蜀铲、目標(biāo)倉庫和目標(biāo)分支边琉。

小紅想要合并功能到正式倉庫，所以源分支是她的功能分支记劝，目標(biāo)倉庫是小明的公開倉庫变姨，而目標(biāo)分支是master分支。另外厌丑，小紅需要提供Pull Request的標(biāo)題和描述信息定欧。如果需要小明以外的人審核批準(zhǔn)代碼，她可以把這些人填在【Reviewers】文本框中怒竿。

image.png

創(chuàng)建好了Pull Request砍鸠，通知會(huì)通過Bitbucket系統(tǒng)消息或郵件（可選）發(fā)給小明。

小明reviewPull Request

image.png

在小明的Bitbucket倉庫頁面的【Pull Request】Tab可以看到所有人發(fā)起的Pull Request耕驰。點(diǎn)擊小紅的Pull Request會(huì)顯示出Pull Request的描述睦番、功能的提交歷史和每個(gè)變更的差異（diff）。

如果小明想要合并到項(xiàng)目中耍属，只要點(diǎn)一下【Merge】按鈕托嚣，就可以同意Pull Request并合并到master分支。

但如果像這個(gè)示例中一樣小明發(fā)現(xiàn)了在小紅的代碼中的一個(gè)小Bug厚骗，要小紅在合并前修復(fù)示启。小明可以在整個(gè)Pull Request上加上評注，或是選擇歷史中的某個(gè)提交加上評注领舰。

image.png

小紅補(bǔ)加提交

如果小紅對反饋有任何疑問夫嗓，可以在Pull Request中響應(yīng)，把Pull Request當(dāng)作是她功能討論的論壇冲秽。

小紅在她的功能分支新加提交以解決代碼問題舍咖，并push到她的Bitbucket倉庫中，就像前一輪中的做法一樣锉桑。這些提交會(huì)進(jìn)入的Pull Request排霉，小明在原來的評注旁邊可以再次review變更。

小明接受Pull Request

最終民轴，小明接受變更攻柠，合并功能分支到master分支，并關(guān)閉Pull Request后裸。至此瑰钮，功能集成到項(xiàng)目中，其它的項(xiàng)目開發(fā)者可以用標(biāo)準(zhǔn)的git pull命令pull這些變更到自己的本地倉庫中微驶。

下一站

到了這里浪谴，你應(yīng)該有了所有需要的工具來集成Pull Request到你自己的工作流。請記住，Pull Request并不是為了替代任何基于Git的協(xié)作工作流苟耻，而是它們的一個(gè)便利的補(bǔ)充篇恒，讓團(tuán)隊(duì)成員間的協(xié)作更輕松方便。

援引：Git工作流指南：Pull Request工作流