什么樣的PR更容易被合入

戰(zhàn)“碼”先鋒，PR征集令（以下簡(jiǎn)稱“戰(zhàn)碼先鋒”）第二期正如火如荼地進(jìn)行中，涉及OpenAtom OpenHarmony（以下簡(jiǎn)稱“OpenHarmony”）主干倉、SIG倉、三方庫，共計(jì)1000+代碼倉任君挑戰(zhàn)。 在活動(dòng)過程中，我們陸續(xù)收到開發(fā)者們提出的一些疑問，其中最主要的一類是：為什么自己的PR沒有被合入？什么樣的PR更容易被合入？為此，我們咨詢了OpenHarmony開發(fā)專家和社區(qū)運(yùn)營(yíng)專家，并整理了這份指引文檔，希望能夠?yàn)榇蠹規(guī)韼椭? 提交的PR更容易被合入，可能是以下4個(gè)原因： ① PR解決的是本領(lǐng)域工程師普遍會(huì)認(rèn)為的問題，大家對(duì)于這次修改的爭(zhēng)議不大。 如圖所示，解壓gcc-arm編譯工具鏈的解壓命令選項(xiàng)書寫錯(cuò)誤：-z是過濾gzip文件，-j是過濾bzip2文件，二者區(qū)別在于對(duì)不同后綴的文件進(jìn)行過濾。此修改僅1個(gè)字符，但十分必要。

② 關(guān)聯(lián)Issue，為提交的PR所解決的問題溯源。 如圖所示，在提交PR的描述中，關(guān)聯(lián)Issue，代碼倉管理員可以點(diǎn)擊Issue查看問題，這樣更清楚這個(gè)PR是為了解決什么問題，也方便了管理員對(duì)此進(jìn)行評(píng)判與合入。

如下圖所示，此修改是因?yàn)榫幾g時(shí)出現(xiàn)告警，但實(shí)際情況并不需要出現(xiàn)告警，所以刪除了編譯告警中多余字符。此PR的具體問題描述，和最終的修改細(xì)節(jié)都與Issue緊密關(guān)聯(lián)并成功解決了問題，這樣的PR更容易被合入。

③ 緊急修改會(huì)優(yōu)先合入：已知的一些問題如果會(huì)影響很多人，需要緊急修改，會(huì)優(yōu)先合入。 更新HB最新版本后，系統(tǒng)顯示告警提示，提示中說明scons、gcc-arm等包在代碼倉中并不適用。社區(qū)小伙伴提交問題后，當(dāng)天就修改代碼提交PR進(jìn)行修復(fù)。為了讓問題快速得到解決，不影響更多開發(fā)者對(duì)代碼的使用，此類緊急需求會(huì)優(yōu)先被關(guān)注并合并。

④ 格式符合提交規(guī)范的PR更容易被合入。 如圖所示，提交Git Commit message的標(biāo)題（head）可以明確PR的類型，比如：特性提升、文檔修改、格式化樣式、重構(gòu)等等；另外，標(biāo)題一般是動(dòng)賓結(jié)構(gòu)，不超過50個(gè)字符（25個(gè)漢字）。 如果修改的內(nèi)容較大，還需要增加一個(gè)消息體（body），講述修改的必要性（necessary），解決了什么問題（address the problem），是否有副作用（side effects）。 Git Commit message的底部（footer）需要補(bǔ)充修復(fù)關(guān)聯(lián)的Issue是什么。如果在修改外接口時(shí)，有產(chǎn)生一些非兼容（BREAKING CHANGE）的影響，也要添加在底部。

上圖右方是提交PR的模板示例，對(duì)應(yīng)補(bǔ)充詳細(xì)描述，有利于提升PR被合入的概率。 在提交PR時(shí)，詳細(xì)描述出原因、目的、解決的問題等，更加全面地闡述此PR做了什么，具體給原來的代碼帶來了什么改變或升級(jí)，并關(guān)聯(lián)對(duì)應(yīng)的Issue，有利于提升PR被合入的概率。 如下圖所示，此PR關(guān)聯(lián)Issue明確問題出處，并在內(nèi)容部分詳細(xì)闡述原因和描述，雖然只有簡(jiǎn)單一句話，但清晰明了地說明了一切，有利于提升PR被合入的概率。

除此之外，PR標(biāo)題也非常重要。如果小伙伴們正在參與戰(zhàn)碼先鋒活動(dòng)，在提交的PR標(biāo)題中需要帶上活動(dòng)標(biāo)簽【OpenHarmony開源貢獻(xiàn)者計(jì)劃2022】，以及具體描述。具體描述旨在用簡(jiǎn)短的一句話總結(jié)貢獻(xiàn)這個(gè)PR的目的，解決了什么問題，也方便閱讀者和管理員的評(píng)審。 以下列舉幾個(gè)優(yōu)秀的PR標(biāo)題案例： 【OpenHarmony開源貢獻(xiàn)者計(jì)劃2022】fix: 'OFFSET_OF_FIELD' redefined https://gitee.com/openharmony/commonlibrary_utils_lite/pulls/101

部分修改截圖 【OpenHarmony開源貢獻(xiàn)者計(jì)劃2022】Simplify realpath code to prevent potential memleak https://gitee.com/openharmony/ai_engine/pulls/186

部分修改截圖 回顧文中提到的4個(gè)點(diǎn)小技巧：①本領(lǐng)域工程師普遍會(huì)認(rèn)為是問題，大家對(duì)于這次修改的爭(zhēng)議不大；②關(guān)聯(lián)Issue，為所解決的問題溯源；③緊急修改會(huì)優(yōu)先合入；④格式符合提交規(guī)范。針對(duì)這4點(diǎn)要求，大家可以對(duì)提交的PR進(jìn)行優(yōu)化，從而提升PR被合入的概率。