源代码管理

分支模式

PX4 项目使用三分支的 Git 分支模式：

• 师 (打开新窗口） 不稳定，发展迅速。
• 测试版 (打开新窗口） 已经过全面测试。它专为飞行测试人员设计。
• 稳定 (打开新窗口） 指向上次发布的版本。

我们尽量保留 通过重建线性历史 (打开新窗口） 并避免 Github 流程 (打开新窗口）.不过，由于团队遍布全球，开发速度很快，我们有时可能会采用合并的方式。

贡献新功能、 注册 Github (打开新窗口）那么 分叉 (打开新窗口） 存储库、 创建新分支 (打开新窗口）添加更改，最后 发送拉取请求 (打开新窗口）.当修改通过我们的 持续集成 (打开新窗口） 测试。

所有代码贡献都必须在允许的 BSD 3 条款许可证 (打开新窗口） 所有代码都不得对使用施加任何进一步的限制。

代码样式格式

PX4 的用途 风格 (打开新窗口） 用于代码格式化。有效版本为

• astyle 2.06 (打开新窗口） （弃用）
• astyle 3.0 (打开新窗口）
• astyle 3.01 (打开新窗口） 推荐

安装后，可使用 ./Tools/astyle/check_code_style_all.sh.输出应为 通过格式检查 在干净的母版上。如果成功了 使格式化 今后可用于自动检查和格式化所有文件。

文件名约定

今后，我们将遵循这些文件命名约定：

• C++ 源文件应以 CamelCase 命名，并与类名一致。例如，一个 C++ 文件包含一个名为 FooThing 应命名为 FooThing.cpp.

• C++ 头文件的命名应与源文件相同，但后缀名应为 .hpp.

• 需要与 C 兼容的 C++ 头文件，其后缀应为 .h.

• 文件夹名称为 蛇箱 内的第一层 模块/司机/systemcmds/etc.，但如果嵌套较深，则应命名为 CamelCase，以便与源文件和头文件相匹配。

• 测试文件必须有 测试 后缀，如图所示： FooThingTest.cpp.

• 上述规则的一个例外是 src/modules/mavlink/streams (打开新窗口） 其中 ALL_UPPERCASE.hpp 与 MAVLink 信息名称相匹配。

源文件

鼓励 PX4 开发人员创建适当的源码内文档。

备注

源代码文档标准没有得到执行，目前的代码文档不一致。我们希望做得更好！

目前，我们有两种基于源代码的文档：

• PRINT_MODULE_* 方法用于模块运行时的使用说明和 模块和命令参考 在本指南中。
  • 该应用程序接口已记录在案 在这里的源代码中 (打开新窗口）.
  • 良好的使用范例包括 应用程序/模块模板 以及模块参考中链接的文件。

• 我们鼓励其他源文件 增加价值/不多余.

  TIP

  开发人员应为 C++ 实体（类、函数、变量等）命名，以便能推断出它们的用途，从而减少对明确文档的需求。

  • 请勿添加可通过 C++ 实体名称推测的文档。
  • 通常情况下，您可能需要添加有关拐角情况和错误处理的信息。
  • 哆可梦 (打开新窗口） 如果需要记录，应使用标记： @ 类, @ 文件, @ 参数, @return, @brief, @var, @see, 注.一个很好的使用例子是 src/modules/events/send_event.h (打开新窗口）.

提交和提交信息

请对所有非小改动使用描述性的多段提交信息。请合理安排提交信息的结构，使其既能在单行摘要中说明问题，又能提供完整的细节。

组成部分：用一句话解释更改。修正 #1234 在摘要行的开头加上软件组件的前缀，可以是模块名称或描述。(例如，"mc_att_ctrl"或 "多旋翼飞行器姿态控制"）。如果问题编号被附加为<Fixes #1234>，Github 将在提交合并到主分支时自动关闭该问题。邮件正文可以包含几个段落。详细描述您修改的内容。链接与此修复或此提交的测试结果相关的问题和飞行日志。描述更改内容和更改原因，避免照搬代码更改内容（好：为 GPS 接收质量低的载具添加额外的安全检查"。坏："添加 gps_reception_check() 函数"）。Reported-by: Name <[email protected]>；

使用 git commit -s 签署所有提交。 这将增加 签署： 最后一行是您的姓名和电子邮件。

本提交指南以 Linux 内核和其他系统的最佳实践为基础。 维护的项目 (打开新窗口） 作者：Linus Torvalds