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

② 關聯Issue，為提交的PR所解決的問題溯源。 如圖所示，在提交PR的描述中，關聯Issue，代碼倉管理員可以點擊Issue查看問題，這樣更清楚這個PR是為了解決什么問題，也方便了管理員對此進行評判與合入。

如下圖所示，此修改是因為編譯時出現告警，但實際情況并不需要出現告警，所以刪除了編譯告警中多余字符。此PR的具體問題描述，和最終的修改細節都與Issue緊密關聯并成功解決了問題，這樣的PR更容易被合入。

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

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

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

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

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

部分修改截圖 回顧文中提到的4個點小技巧：①本領域工程師普遍會認為是問題，大家對于這次修改的爭議不大；②關聯Issue，為所解決的問題溯源；③緊急修改會優先合入；④格式符合提交規范。針對這4點要求，大家可以對提交的PR進行優化，從而提升PR被合入的概率。