# 源代码管理

# 分支模型

PX4 项目使用三分支 Git 模型:

我们试着 通过重置保留线性历史 (opens new window),并且避免 Github flow (opens new window)。 然而,由于全球团队和快速的发展,我们可能有时会进行合并。

要贡献新功能,注册Github (opens new window),然后 fork (opens new window) 仓库,创建一个新分支 (opens new window),添加您的更改,最后 发送拉取请求 (opens new window)。 更改将在通过我们的 持续整合 (opens new window) 测试时合并。

所有代码贡献都必须在许可的 BSD 3 条款的许可证 (opens new window) 下进行,不得对其使用施加任何进一步的限制。

# 代码样式格式

PX4 使用 asty (opens new window) 进行代码格式化。 有效版本是

一旦安装完毕,格式化可以使用 .工具/astyle/check_code_style_all.sh。 一个干净的 master 分支的输出应该是 格式检查通过。 如果做到这一点,制作格式将来可以自动检查和格式化所有文件。

# 源文件

鼓励PX4开发者创建适当的源文档。

  • C++ source files should be named in CamelCase and match the class name. E.g. A C++ file containing a class named FooThing should be named FooThing.cpp.

  • C++ header files should be named the same as source files except have the suffix .hpp.

  • C++ header files that are required to be C compatible, should have the suffix .h.

  • Folder names are snake_case for the first level inside modules/drivers/systemcmds/etc. but should be named CamelCase when more deeply nested to match the source and header files.

  • Test files must have a Test suffix as shown: FooThingTest.cpp.

  • One exception to the rules above are the MAVLink streams in src/modules/mavlink/streams (opens new window) which are ALL_UPPERCASE.hpp matching the MAVLink message name.

# 提交和提交消息

PX4 developers are encouraged to create appropriate in-source documentation.

注解

Source-code documentation standards are not enforced, and the code is currently inconsistently documented. We'd like to do better!

Currently we have two types of source-based documentation:

  • We encourage other in-source documentation where it adds value/is not redundant.

    提示

Developers should name C++ entities (classes, functions, variables etc.) such that their purpose can be inferred - reducing the need for explicit documentation. :::

# Commits and Commit Messages

Please use descriptive, multi-paragraph commit messages for all non-trivial changes. Structure them well so they make sense in the one-line summary but also provide full detail.

组成部分:在一个句子中解释这一更改。 修复 #1234

将软件组件添加到摘要行的开头,或者通过模块名称或它的描述。
(例如,"mc_att_ctrl" 或 "multicopter 姿态控制器")。

如果问题编号作为<Fixes #1234>添加,Github 将在提交合并到主分支时自动关闭问题。

电文正文可以包含几个段落。
详细描述您的变更。 链接问题和飞行日志或与此项提交的测试结果有关联。

描述这个变化以及你为什么做了修改,而不是只有代码更改内容 (很好: "为低质量GPS 接收的车辆添加额外
安全检查"。
坏: "添加 gps_reception_check() 函数").

已上报:名字 <email@px4.io>

Use git commit -s to sign off on all of your commits. This will add signed-off-by: with your name and email as the last line.

This commit guide is based on best practices for the Linux Kernel and other projects maintained (opens new window) by Linus Torvalds.