Git是最流行的代碼版本控制系統(tǒng)，這一系列文章介紹了一些Git的高階使用方式，從而幫助我們可以更好的利用Git的能力。本系列一共8篇文章，這是第3篇。原文：Better Collaboration With Pull Requests[1]
本文是“Git進(jìn)階系列”的第三篇，將介紹pull request這一對大型和小型開發(fā)團(tuán)隊(duì)都很有幫助的超棒特性。Pull request不僅改進(jìn)了評審和反饋過程，還有助于跟蹤和討論代碼變更。最后重要的一點(diǎn)是，pull request是向其他沒有寫訪問權(quán)限的代碼庫貢獻(xiàn)內(nèi)容的理想方式。
Git進(jìn)階系列:
什么是Pull Request?
首先需要知道，pull request不是Git核心特性。相反，是由使用的Git托管平臺提供的，GitHub、GitLab、Bitbucket、AzureDevops以及其他平臺都提供類似的內(nèi)置功能。
為什么需要創(chuàng)建pull request?
在我們討論如何創(chuàng)建完美的pull request的細(xì)節(jié)之前，先來討論一下為什么需要這個特性。
假設(shè)我們剛剛完成軟件的一個新特性，也許之前一直在特性分支中工作，因此下一步將是將其合并到主線分支(master分支或main分支)。在某些情況下，比方說你是項(xiàng)目中唯一的開發(fā)人員，或者有足夠的經(jīng)驗(yàn)并確定團(tuán)隊(duì)成員不會提出異議，那么直接合并一點(diǎn)問題都沒有。
不過如果代碼變更稍微復(fù)雜一點(diǎn)，并且希望其他人能夠檢查這部分工作，該怎么辦呢？這就是pull request的目的。有了pull request，可以邀請其他人來評論所作的工作并給出反饋。
一旦創(chuàng)建了pull request，就可以和其他開發(fā)人員討論相關(guān)代碼。大多數(shù)Git托管平臺允許其他用戶在此過程中添加評論以及提出建議，當(dāng)評審人員批準(zhǔn)后，就可以將其合并到另一個分支中。
評審工作流并不是創(chuàng)建pull request的唯一原因。如果想對其他沒有寫訪問權(quán)限的代碼庫做出貢獻(xiàn)，用pull request就會很方便。想想所有的開源項(xiàng)目，如果你有一個新特性的想法，或者如果想提交一個補(bǔ)丁，pull request是一個很好的方式來展示想法，而不必加入這個項(xiàng)目并成為主要貢獻(xiàn)者。
這就引出了一個與pull request緊密相關(guān)的話題: fork。
用fork工作
fork是現(xiàn)有Git代碼庫的個人副本?；氐街瓣P(guān)于開源的示例，第一步是創(chuàng)建原始代碼庫的副本（fork），之后就可以在自己的個人副本中更改代碼。
一旦完成，就可以創(chuàng)建一個pull request，要求原始代碼庫的維護(hù)者采用你的更改。維護(hù)者或其他主要貢獻(xiàn)者可以檢查相關(guān)代碼，然后決定是否采用。
重要提示: Pull request總是基于分支，而不是單個提交！創(chuàng)建pull request時，需要基于一個特定的分支并請求采用。
讓審閱者的生活更輕松: 如何創(chuàng)建一個優(yōu)秀的pull request
如前所述，pull request并不是Git的核心特性。相反，每個Git平臺都有自己的設(shè)計以及關(guān)于pull request如何工作的想法。這些設(shè)計在GitLab, GitHub, Bitbucket等平臺上看起來都不太一樣，每個平臺都有略微不同的工作流，用于跟蹤、討論和審查更改。
無論使用什么代碼托管服務(wù)，Tower Git客戶端這樣的桌面GUI能夠提供一致的用戶界面，讓這一切都變得更容易。
盡管如此，一般的工作流程都差不多，包括以下步驟:
- 如果你沒有對代碼庫的寫權(quán)限，第一步是創(chuàng)建一個fork，也就是個人版本的代碼庫。
- 在fork的代碼庫中創(chuàng)建新的本地分支。(提示: pull request是基于分支的，而不是提交!)
- 在本地分支中進(jìn)行變更并提交。
- 將變更推送到自己的遠(yuǎn)程代碼庫。
- 創(chuàng)建一個包含相關(guān)變更的pull request，開始與他人討論。
我們看看pull request本身，以及如何創(chuàng)建讓其他開發(fā)人員的生活更輕松的請求。首先應(yīng)該簡短，以便快速審閱，當(dāng)面對3000行代碼而不是30行代碼時，就很難理解代碼了。
其次，確保添加良好的、不言自明的標(biāo)題和有意義的描述。試著描述做了哪些更改，為什么創(chuàng)建pull request，以及這些更改對項(xiàng)目的影響。大多數(shù)平臺都允許添加屏幕截圖來幫助展示這些變化。
批準(zhǔn)、合并還是拒絕?
一旦變更被批準(zhǔn)，你(或具有寫訪問權(quán)的人)就可以將分支合并到主分支中。但是，如果審閱者不想在當(dāng)前狀態(tài)下合并pull request，該怎么辦？嗯，你可以等會兒，也可以將新的提交推送到那個分支上，這樣現(xiàn)有的pull request也會更新。
此外，維護(hù)者或其他具有寫訪問權(quán)限的人可以在不想合并更改時拒絕pull request。
開發(fā)人員的安全網(wǎng)
如你所見，pull request是與其他開發(fā)人員溝通協(xié)作的好方法。通過讓其他人檢查所作的工作，可以確保只有高質(zhì)量的代碼進(jìn)入代碼庫。
如果想更深入了解高級Git工具，可以免費(fèi)查看“Advanced Git Kit[3]”: 這是關(guān)于分支策略、交互式Rebase、Reflog、子模塊等主題的短視頻集合。
References:
[1] Better Collaboration With Pull Requests: https://css-tricks.com/better-collaboration-with-pull-requests/
你好，我是俞凡，在Motorola做過研發(fā)，現(xiàn)在在Mavenir做技術(shù)工作，對通信、網(wǎng)絡(luò)、后端架構(gòu)、云原生、DevOps、CICD、區(qū)塊鏈、AI等技術(shù)始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續(xù)學(xué)習(xí)、終身成長，歡迎一起交流學(xué)習(xí)。
微信公眾號：DeepNoMind
