什么样的PR更容易被合入

战“码”先锋，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被合入的概率。

审核编辑：彭静