Skip to content

拉取请求指南#

通用拉取请求工作流程#

Autoware 使用分叉和拉动模型. 有关该模型的更多详细信息,请参阅 GitHub Docs.

以下是基于 fork-and-pull 模型的拉取请求工作流程的一般示例. 当您为 Autoware 做出贡献时,请使用此工作流作为参考.

  1. 创建一个 issue.
  2. 创建复刻存储库.(仅限第一次)
  3. 根据 Issue 中商定的方法在您的 fork 存储库中编写代码.
  4. 测试代码.
    • 建议您总结测试结果,因为您需要在后面的审核过程中解释测试结果.
    • 如果您不确定应该进行哪些测试,请与维护者讨论.
  5. 创建拉取请求.
  6. 等待拉取请求被审查.
  7. 解决审稿人指出的审稿意见.
    • 如果您不理解评论评论的含义,请询问评论者,直到您理解为止.
      • 不建议在不了解原因的情况下进行修复,因为作者应该对自己的 pull request 的最终内容负责.
    • 如果您不同意评论,请向评论者询问合理的理由.
      • 审阅者有义务让作者理解每条评论的含义.
    • 完成审阅评论后,重新向审阅者请求审阅,并返回到 6.
      • 尽可能避免使用 force push,以便审阅者只能看到差异.更准确地说,至少将提交历史记录保留到审查点,因为 GitHub Web UI(例如建议的更改)可能需要变基才能通过 DCO CI.
    • 如果没有更多的新审查评论,审查者将批准拉取请求并继续执行 8.
  8. 合并拉取请求.
    • 如果维护者没有特殊要求,任何具有写入权限的人都可以合并拉取请求.
      • 鼓励作者合并拉取请求,以便对自己的拉取请求负责.
      • 如果作者没有写入权限,请询问审阅者或维护者.

拉取请求规则#

使用适当的拉取请求模板(必需,非自动化)#

理由#

  • 模板的描述样式统一,可以提高审核效率.

示例#

有两种类型的模板.根据以下条件选择一个.

  1. 标准变更： -复杂性： - 新功能或重大更新. - 需要对代码库有更深入的了解. -冲击： - 影响系统的多个部分. - 基本上包括次要功能、错误修复和性能改进. - 合并前需要测试.
  2. 【小改动】(https://github.com/autowarefoundation/autoware/blob/main/.github/PULL_REQUEST_TEMPLATE/small-change.md)： -复杂性： - 文档、简单重构或样式调整. - 易于理解和审查. -冲击： - 对系统的影响最小. - 合并速度更快,需要的测试更少.
使用适当拉取请求模板的步骤#
  1. 选择合适的模板,如 本视频 所示.
  2. 仔细阅读所选模板并填写所需内容.
  3. 在审核期间选中复选框.

创建拉取请求后设置适当的审阅者(必需,部分自动化)#

理由#

  • 拉取请求必须由适当的审阅者审查,以保持代码库的质量.

示例#

  • 对于大多数 ROS 包,将根据 package.xml 中的 maintainer 信息自动分配审阅者.
  • 如果未自动分配审阅者,请按照 GitHub Docs 中的说明手动分配审阅者.
    • 您可以通过查看存储库的 .github/CODEOWNERS 文件来找到审阅者.
  • 如果您不确定合适的审阅者,请询问 @autoware-maintainers.
  • 如果您无权分配审阅者,请改为提及审阅者.

将约定式提交应用于拉取请求标题(必需,自动)#

理由#

示例#

feat(trajectory_follower): add an awesome feature

注意

您必须以小写字母开始描述部分(此处为 add an awesome feature).

如果您的更改破坏了某些接口,请使用 ！ (破坏性更改) 标记,如下所示：

feat(trajectory_follower)!: remove package
feat(trajectory_follower)!: change parameter names
feat(planning)!: change topic names
feat(autoware_utils)!: change function names

对于包含代码的存储库(大多数存储库),请使用 definition of conventional-commit-types 作为类型.

对于诸如 autoware-documentation 之类的文档存储库,请使用以下定义：

  • feat
    • 添加新页面.
    • 向现有页面添加内容.
  • fix
    • 修复现有页面中的内容.
  • refactor
    • 将内容移动到不同的页面.
  • docs
    • 更新文档存储库本身的文档.
  • build
    • 更新文档站点构建器的设置.
  • ! (重大更改)
    • 删除页面.
    • 更改页面的 URL.

perf 和 test 通常未使用. 其他类型与代码仓库具有相同的含义.

将相关组件名称添加到约定提交 (咨询, 非自动化) 的范围#

理由#

  • 它可以帮助贡献者找到与他们相关的拉取请求.
  • 它使变更日志更清晰.

示例#

对于 ROS 包,最好添加包名称或组件名称.

feat(trajectory_follower): add an awesome feature
refactor(planning, control): use common utils

保持拉取请求较小(咨询性,非自动化)#

理由#

  • 小型拉取请求对于审阅者来说很容易理解.
  • 维护者很容易恢复小的拉取请求.

异常#

如果与维护者达成一致,除了提交一个大的 pull request 之外别无他法,这是可以接受的.

示例#

  • 避免在一个拉取请求中开发两个功能.
  • 避免在同一提交中混合不同类型的更改(feat、fix、refactor 等).

如果超过一周没有回复,则提醒审阅者(咨询,非自动化)#

理由#

  • 作者有责任关心自己的 pull request,直到它被合并.

示例#

@{some-of-developers} Would it be possible for you to review this PR?
@autoware-maintainers friendly ping.