源代码管理
分支模型
PX4 项目使用三分支 Git 模型:
我们试着 通过重置保留线性历史,并且避免 Github flow。 然而,由于全球团队和快速的发展,我们可能有时会进行合并。
要贡献新功能,注册Github,然后 fork 仓库,创建一个新分支,添加您的更改,最后 发送拉取请求。 更改将在通过我们的 持续整合 测试时合并。
所有代码贡献都必须在许可的 BSD 3 条款的许可证 下进行,不得对其使用施加任何进一步的限制。
代码样式格式
PX4 使用 asty 进行代码格式化。 有效版本是
astyle 2.06(推荐)
astyle 3.01 (recommended)
一旦安装完毕,格式化可以使用 .工具/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 namedFooThing.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 insidemodules
/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 which are ALL_UPPERCASE.hpp matching the MAVLink message name.
提交和提交消息
PX4 developers are encouraged to create appropriate in-source documentation.
Currently we have two types of source-based documentation:
PRINT_MODULE_*
methods are used for both module run time usage instructions and for the Modules & Commands Reference in this guide.The API is documented in the source code here.
Good examples of usage include the Application/Module Template and the files linked from the modules reference.
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.
Do not add documentation that can trivially be assumed from C++ entity names.
Commonly you may want to add information about corner cases and error handling.
Doxgyen tags should be used if documentation is needed:
@class
,@file
,@param
,@return
,@brief
,@var
,@see
,@note
. A good example of usage is src/modules/events/send_event.h.
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.
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 by Linus Torvalds.
Last updated