Pull Request是Bitbucket、GitHub等源代碼托管系統(tǒng)為了方便開發(fā)者之間協(xié)作而提供的一個功能，它提供了一個用戶友好的Web界面來幫助審查人員進行代碼審查。開發(fā)人員可以通過GitHub發(fā)出Pull Requests要求請求他人將程序拉下來進行代碼審查。一個好的Pull Request不僅僅只是代碼的事情，還牽涉到代碼審查者對代碼的審查，所以開發(fā)者不僅要寫出好的代碼，還必須迎合審查者的審查工作，才能給使得自己貢獻的代碼順利通過審查并合并到master分支?，F(xiàn)對丹麥的程序員、軟件架構(gòu)師、獨立顧問Mark Seemann在自己博客中發(fā)布的一篇題為《關(guān)于Pull Request的十個建議》的文章進行一個全面的整理，以供讀者閱讀和參考。具體內(nèi)容如下：
一個小且集中的Pull Request會使得提交的代碼更加容易通過審核。據(jù)Mark Seemann根據(jù)自己的經(jīng)驗透漏，對提交代碼進行審查所花費的時間是隨著代碼大小呈指數(shù)增長，而非線性增長；Pull Request多大才合適與Pull Request做了什么相關(guān)，最好少于12個文件的改變。如果Pull Request非常大，審查者就需要安排連續(xù)、相對比較長的時間進行審查，就會造成審查過程的延遲。
就如軟件設(shè)計模式中的單一責(zé)任原則所指：一個類只負責(zé)一個功能領(lǐng)域中的相應(yīng)職責(zé)，因此一個Pull Request也應(yīng)只關(guān)注一件事情。如果一次Pull Request做了多件事情的話，將會增加審查過程的延遲、審查被拒絕的可能性。
代碼審查者會使用不同的審查工具來審查提交的代碼，并且GitHub和Stash還提供了不同形式的視圖，這樣就使得代碼審查者能通過不同視圖非常方便來審查用戶的提交。如果代碼行比較寬的話，審查者就不能在一個屏幕或者半個屏幕中來閱讀代碼，不得不拖動滾動條來閱讀代碼。為了使得代碼比較容易審查，每行代碼最好少于80個字符。
就算自己覺得應(yīng)該改變當(dāng)前代碼的格式以適合自己的風(fēng)格，但是請不要這么做。在源代碼上，用戶對每個字節(jié)的改變將會在不同的審查視圖顯示出來。有些審查者會選擇忽略空格改變，但是有些審查者會審查這些代碼，對這些格式化引起的代碼審查屬于不必要的審查。如果真需要解決空格問題的話，就需要在其他文件里移動代碼、改變格式或者對代碼做其他樣式改變，并在Pull Request注釋中給出相應(yīng)的說明。
在提交Pull Request時，應(yīng)該首先在自己的電腦上進行編譯構(gòu)建。在編譯構(gòu)建過程中，務(wù)必注意編譯過程出現(xiàn)的警告，要把警告當(dāng)作錯誤來對待，這些警告可能不會阻止編譯，就有可能被忽略。然而，當(dāng)用戶Pull Request操作引起了很多編譯警告的話，代碼審查者就有可能拒絕對應(yīng)的提交。
即使問題代碼已經(jīng)做了自動化測試，但是在提交Pull Request時，也要務(wù)必保證針對代碼的所有測試都必須通過。
為代碼建立測試規(guī)則，即使出現(xiàn)問題的代碼已經(jīng)做過了自動化測試，最好也要為自己提交的代碼也做下測試。
利用文檔對代碼進行注釋、對自己的代碼直接進行注釋、利用版本控制器提供的提交信息功能備注信息、利用Pull Request 管理系統(tǒng)（如GItHub或者Stash）添加自定義的Pull Request注釋信息。
按照代碼正確性規(guī)則編寫代碼，并附上有效的代碼注釋、提交信息、Pull Request信息等。
不同審查者對Pull Request有可能具有不同的觀點，這就會導(dǎo)致顛簸的情況，就需要用戶移除沖突的提交和推送修改的分支，并備注有效的信息。
感謝郭蕾對本文的審校。
給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關(guān)注我們，并與我們的編輯和其他讀者朋友交流。
相關(guān)內(nèi)容
Pull Request是Bitbucket、GitHub等源代碼托管系統(tǒng)為了方便開發(fā)者之間協(xié)作而提供的一個功能，它提供了一個用戶友好的Web界面來幫助審查人員進行代碼審查。開發(fā)人員可以通過GitHub發(fā)出Pull Requests要求請求他人將程序拉下來進行代碼審查。一個好的Pull Request不僅僅只是代碼的事情，還牽涉到代碼審查者對代碼的審查，所以開發(fā)者不僅要寫出好的代碼，還必須迎合審查者的審查工作，才能給使得自己貢獻的代碼順利通過審查并合并到master分支?，F(xiàn)對丹麥的程序員、軟件架構(gòu)師、獨立顧問Mark Seemann在自己博客中發(fā)布的一篇題為《關(guān)于Pull Request的十個建議》的文章進行一個全面的整理，以供讀者閱讀和參考。具體內(nèi)容如下：
一個小且集中的Pull Request會使得提交的代碼更加容易通過審核。據(jù)Mark Seemann根據(jù)自己的經(jīng)驗透漏，對提交代碼進行審查所花費的時間是隨著代碼大小呈指數(shù)增長，而非線性增長；Pull Request多大才合適與Pull Request做了什么相關(guān)，最好少于12個文件的改變。如果Pull Request非常大，審查者就需要安排連續(xù)、相對比較長的時間進行審查，就會造成審查過程的延遲。
就如軟件設(shè)計模式中的單一責(zé)任原則所指：一個類只負責(zé)一個功能領(lǐng)域中的相應(yīng)職責(zé)，因此一個Pull Request也應(yīng)只關(guān)注一件事情。如果一次Pull Request做了多件事情的話，將會增加審查過程的延遲、審查被拒絕的可能性。
代碼審查者會使用不同的審查工具來審查提交的代碼，并且GitHub和Stash還提供了不同形式的視圖，這樣就使得代碼審查者能通過不同視圖非常方便來審查用戶的提交。如果代碼行比較寬的話，審查者就不能在一個屏幕或者半個屏幕中來閱讀代碼，不得不拖動滾動條來閱讀代碼。為了使得代碼比較容易審查，每行代碼最好少于80個字符。
就算自己覺得應(yīng)該改變當(dāng)前代碼的格式以適合自己的風(fēng)格，但是請不要這么做。在源代碼上，用戶對每個字節(jié)的改變將會在不同的審查視圖顯示出來。有些審查者會選擇忽略空格改變，但是有些審查者會審查這些代碼，對這些格式化引起的代碼審查屬于不必要的審查。如果真需要解決空格問題的話，就需要在其他文件里移動代碼、改變格式或者對代碼做其他樣式改變，并在Pull Request注釋中給出相應(yīng)的說明。
在提交Pull Request時，應(yīng)該首先在自己的電腦上進行編譯構(gòu)建。在編譯構(gòu)建過程中，務(wù)必注意編譯過程出現(xiàn)的警告，要把警告當(dāng)作錯誤來對待，這些警告可能不會阻止編譯，就有可能被忽略。然而，當(dāng)用戶Pull Request操作引起了很多編譯警告的話，代碼審查者就有可能拒絕對應(yīng)的提交。
即使問題代碼已經(jīng)做了自動化測試，但是在提交Pull Request時，也要務(wù)必保證針對代碼的所有測試都必須通過。
為代碼建立測試規(guī)則，即使出現(xiàn)問題的代碼已經(jīng)做過了自動化測試，最好也要為自己提交的代碼也做下測試。
利用文檔對代碼進行注釋、對自己的代碼直接進行注釋、利用版本控制器提供的提交信息功能備注信息、利用Pull Request 管理系統(tǒng)（如GItHub或者Stash）添加自定義的Pull Request注釋信息。
按照代碼正確性規(guī)則編寫代碼，并附上有效的代碼注釋、提交信息、Pull Request信息等。
不同審查者對Pull Request有可能具有不同的觀點，這就會導(dǎo)致顛簸的情況，就需要用戶移除沖突的提交和推送修改的分支，并備注有效的信息。
