将修补程序提交回主程序

./_images/PullRequest_TopImage.png

一旦您想在 ArduPilot 项目中加入错误修复或新功能，应提交一份 拉取请求.主开发人员会在 拉动列表、 如果一切顺利，它们将被合并到主文件中。

本页将为您提供建议，帮助您顺利完成申请过程。

准备提交

  • 承诺应 在新的分支中 你的 分叉/复制 (即不是 "master"）。这些工作应在本地分支上完成，然后推送到基于网络的 ArduPilot 分支。

  • 新分支应为 有新意 与 ArduPilot/master 而不应包括任何其他更改。

  • 承诺应该小而精，只做一件事。 如果一个修改涉及多个库，那么每个库和每个载体目录都应该有单独的提交。即使这意味着中间提交会破坏构建，也应如此。

  • 文字精炼、简明扼要的评论 鼓励

    提交信息的格式应为

    子系统: 简介 描述

更长 描述...

    例如

    APM_Control: 减小 的 编号 的 规范 节省 于 自动调整

做 不 节省 a 规范 除非 它 有 变了 由 0.1%

  • 清理本地提交历史 使用交互式数据库 （即 git 躏 -i "HEAD~10"；)来重新排列补丁并将其折叠在一起。这样做的目的是为审查提供一套合理的补丁。要习惯交互式重新编排可能需要一些努力，但绝对值得一学。请参考 在线资源 以了解如何使用该工具。

  • 更改的提交应被压制（参见 交互式重置：清理提交)合并为一个提交，然后运行 "Tools/gittools/git-subsystems-split "脚本为每个受影响的库模块创建一个提交。

  • 请勿提交带有注释代码的补丁，也不要提交在以下情况下永远无法访问的代码 #define s.

  • 尽量按照 风格指南 以便您的代码与现有代码保持一致。尤其要确保您的编辑器使用 4 个空格而不是制表符。

  • 使用 Unix 行结束符 (LF)。Git 应该会自动处理这个问题，但如果你发现有很多文件在 git 地位 但您没有触及这些文件，您可能需要 检查本地 git 行尾设置是否正确.

  • 读取您的修改，进行自己的审核。最好的方法是使用 "gitk "工具。认真阅读自己的改动。确保其中不包含任何你不想放入拉取请求的内容。最好在写完代码几个小时后再看自己的改动，最好是第二天。仔细查看并查找任何错误。

  • 如果您可以访问 Linux 构建环境，那么使用 Tools/scripts/build_all.sh.这将测试所有针对不同板卡和载具类型的构建是否有效。如果您没有 Linux 构建环境，那么请测试 Pixhawk 板、漫游车、旋翼飞行器和飞机的构建，如果您的更改可能会影响这些飞行器。

  • 在 SITL 如果可能的话。如果无法运行 SITL，则在真实载具中测试您的更改。

提交拉取请求

要提交 GitHub 上的拉取请求 请按照以下说明进行操作：

  1. 打开您的 分叉 在 GitHub 网页的下拉菜单中选择分支，然后按下 "新建拉取请求 "按钮

    ../_images/PullRequest_InitiatePullRequest1.png

  2. 检查 "基本叉 "是否 ArduPilot/ardupilot 基础 "为 "主"，然后填写 PR 的主题行和详细说明。详细描述应包括所进行测试的任何证据。

    检查页面底部的更改列表中是否只包含您打算进行的更改，然后按下 "创建拉取请求 "按钮。

    ../_images/PullRequest_InitiatePullRequest2.png

下一步工作

您可以通过 拉取请求列表.

如果具备以下条件，则 PR 更有可能被快速合并：

  • 公关明确指出预期行为会发生哪些变化

  • 提供良好的测试证据。这可以是更改前后记录的日志图表

  • 公关在 每周开发电话.要让 PR 得到讨论，请添加 "DevCallTopic "标签。如果您无法添加标签，请在 ArduPilot 纪谈

核心开发人员要求您修改拉取请求以更好地适应现有代码库或解决您可能不知道的一些连锁影响是很常见的，尤其是对于大型变更。请不要误解，我们绝对不是想让您为难！