嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载本文以 PX4-Autopilot 仓库的 Pull Request 提交流程为纲完整还原一次 PR 从创建特性分支到提交并返回 PR 链接的七步标准操作并结合仓库内的 CI 校验脚本与贡献规范深入讲解 PR 标题、正文的格式要求以及 AI 辅助贡献的披露规则。读完本文你将能按 PX4 官方规范一次性提交格式正确、可被维护者快速评审的 Pull Request。背景PX4 的 PR 文化PX4-Autopilot 是安全攸关的飞行控制固件其代码合入有着比普通开源项目更严格的纪律。仓库 CONTRIBUTING.md 明确要求所有提交信息与 PR 标题遵循 Conventional Commits 格式并且强调PR 标题在 squash-merge 时会直接成为提交信息因此标题质量直接影响主线提交历史的可读性。与此配套仓库内有一套 CI 脚本专门校验提交信息与 PR 标题的合规性Tools/ci/check_pr_title.py校验 PR 标题是否符合type(scope): description格式不合法时输出建议修正的标题Tools/ci/check_commit_messages.py读取 GitHub API 返回的 PR 提交列表逐条检查阻塞性错误与建议性警告Tools/ci/conventional_commits.py上述两个脚本共用的解析与建议引擎定义了合法的 type 集合、scope 关键词映射与标题正则。本文描述的标准 PR 工作流共七步全部可由一个具备Bash、Read、Glob、Grep工具能力的 AI Agent 或开发者手动完成。第一步检查分支并创建特性分支PR 永远不应直接基于main提交。工作流的第一步是检查当前分支git branch --show-current如果当前位于main必须创建一个特性分支命名规范为username/description其中username来自当前 GitHub 账号可通过 GitHub CLI 获取gh api user --jq .login例如用户名为alice改动内容是添加 EKF2 高度融合超时则分支名为alice/ekf2-height-fusion-timeout。分支名中的 description 应当与后续 PR 标题的 description 保持一致使分支、提交与 PR 三者语义贯通。第二步收集改动上下文在撰写 PR 之前需要完整了解本次改动的范围。标准做法是执行以下四个检查# 1. 查看工作区是否有未提交改动 git status # 2. 查看当前分支相对 main 的所有提交 git log --oneline main..HEAD # 3. 查看相对 main 的改动统计变更了哪些文件、增删了多少行 git diff main...HEAD --stat # 4. 检查是否存在远程跟踪分支判断是否已推送过 git status -sb # 或 git rev-parse --abbrev-ref --symbolic-full-name {u}这三个检查回答了撰写 PR 时最关键的三个问题改了什么stat、有哪些提交log、是否需要推送remote tracking。这些信息决定了后续 PR 标题如何概括、正文如何描述问题与方案以及是否需要-u参数首次推送。第三步构建验证Sanity BuildPX4 是编译产物直接上机的项目提 PR 前必须确保改动能够编译通过。工作流要求构建一个该改动实际能影响到的目标改动类型应构建的目标固件改动驱动、模块、板级代码对应受影响的目标板例如make px4_fmu-v6x仅 POSIX / 仿真改动px4_sitlSITL 目标无法触及任何编译目标submodule 指针更新、文档、ROMFS跳过构建后一条规则很关键并非每个 PR 都需要构建。当git diff main...HEAD --stat显示改动仅涉及docs/、ROMFS/启动脚本、子模块指针等内容时直接跳过构建避免无意义的 CI 等待。若改动触及编译目标但构建失败必须在开 PR 之前修复所有构建错误。从源码结构看PX4 的 SITL 目标定义于 boards/px4/sitl而各板级目标位于 boards 目录下各自的*.px4board配置中构建系统入口为仓库根目录的 Makefile 与 CMakeLists.txt。第四步撰写 PR 标题——遵循 Conventional CommitsPR 标题是整个 PR 最重要的元数据因为它会成为 squash-merge 后的提交信息。格式为type(scope): description要求总长不超过 72 个字符必须覆盖该 PR 全部提交的整体改动而非只描述某一个 commit一旦通过 squash-merge 合入这个标题就是main上的提交信息。type 与 scope 的合法取值根据 CONTRIBUTING.md 与 Tools/ci/conventional_commits.py 中定义的CONVENTIONAL_TYPES合法的 type 为type含义feat新功能fix缺陷修复docs仅文档改动style格式、空白无代码逻辑变化refactor既非修 bug 也非新功能的代码重构perf性能改进test新增或修正测试build构建系统或外部依赖ciCI 配置与脚本chore不修改 src 或 test 文件的其他改动revert回滚之前的提交scope 标识受影响的模块、驱动、板子或领域。常用取值包括ekf2、mavlink、commander、navigator、sensors、drivers、mc_att_control、mc_pos_control、fw_att_control、vtol、actuators、battery、logger、param、simulation、ci、docs、build、uorb等。跨多个子系统的改动取主要影响的那个也可以直接看改动文件所在路径推断例如src/modules/ekf2/下的改动用ekf2src/drivers/imu/下的改动用drivers/imu。CI 如何校验标题Tools/ci/check_pr_title.py 在 CI 中对 PR 标题做正则匹配。其核心正则定义于 Tools/ci/conventional_commits.pyHEADER_PATTERN re.compile( r^( |.join(CONVENTIONAL_TYPES.keys()) r) r\(([a-zA-Z0-9_/\-\.])\) r(!)? r: (.{5,})$ )从中可以提取出 CI 的硬性规则type 必须是上表 11 个取值之一scope 必须存在且只能包含字母、数字、下划线、斜杠、连字符和点!可选放在冒号前表示 breaking change破坏性变更例如feat(ekf2)!: remove deprecated height fusion APIdescription 至少 5 个字符且必须以冒号空格分隔。当标题不合法时脚本还会尝试自动给出修正建议剥离[docs]这类方括号前缀、将旧式subsystem: description转换为新格式、甚至根据描述文本中的关键词推断 type 与 scope见suggest_title、suggest_type、suggest_scope。CI 会以 PR 评论的形式把建议标题贴出来。好的与坏的标题示例CONTRIBUTING.md 给出的范例feat(ekf2): add height fusion timeout fix(mavlink): correct BATTERY_STATUS_V2 parsing refactor(navigator): simplify RTL altitude logic ci(workflows): migrate to reusable workflows docs(ekf2): update tuning guide feat(boards/px4_fmu-v6x)!: remove deprecated driver API perf(mc_rate_control): reduce loop latency会被 CI 标记的糟糕标题fix # 太模糊缺 type/scope update # 太模糊 ekf2: fix something # 缺 type 前缀 apply suggestions from code review # 应 squash 进父提交 do make format # 应 squash 进父提交 WIP: trying something # 未就绪 oops # 无描述性第五步撰写 PR 正文——三段式极简结构PX4 的 PR 正文哲学是短到评审者一眼能看完——过长的描述反而没人读。正文必须且只能包含三个小节按顺序排列## Summary ## Problem ## Solution每节一两句话即可。硬性要求不要复述 diff不列变更文件清单不放代码片段不要提 CI不要重复标题已经说过的内容如果 PR 关闭某个 issue## Summary的第一行必须是fixes #N之后空一行再接摘要正文不设## Test plan小节不要模板化套话不要有任何 AI 归属声明如 Generated with Claude 之类的 footer详见后文 AI 披露一节。测试陈述的真实性原则这是 PX4 评审中非常看重的一条绝不声称没有发生的测试。正确的做法是主动询问用户实际运行过什么SITL、台架测试还是真机飞行如实报告测试内容没有测试就明确说未测试。结合 CONTRIBUTING.md 的测试要求新功能必须尽量附带单元测试和/或集成测试bug 修复尽量附带回归测试无法自动化测试的硬件相关改动应提供台架或飞行测试证据如 Flight Review 日志链接。PX4 是安全攸关软件评审者会在批准前核对测试或测试证据是否存在——因此正文里一句诚实的未测试远好于一段虚假的测试描述。第六步推送并创建 PR改动就绪后若分支尚未推送过使用-u设置上游并推送git push -u origin username/description然后通过 GitHub CLI 创建 PRgh pr create默认基准分支base为main除非用户明确指定其他目标分支。若用户在发起任务时提供了额外参数如目标分支或描述将其作为上下文用于完善标题与正文。第七步返回 PR 链接创建成功后将gh pr create输出的 PR URL 返回给用户整个流程结束。附AI 辅助贡献的披露规则该 PR 工作流在设计时明确假定用户人类是作者。两条核心红线不得添加Co-Authored-By署名也不得在 PR 正文添加 Generated with Claude 之类的 footerAI 使用情况必须通过提交信息的 trailer 披露而不是放在 PR 正文里。披露格式为提交信息体中的 trailerAssisted-by: NAME:MODEL其中NAME是工具名、MODEL是具体模型名例如Assisted-by: Claude:claude-fable-5 Assisted-by: Copilot:gpt-5这条规则与仓库的 AI 辅助贡献政策 docs/en/contribute/ai_assistants.md 一致AI 工具永远不会是作者或合著者绝不出现于Signed-off-by标签中人类提交者必须理解并能捍卫提交的每一行。Signed-off-by仍是人类作者对 Developer Certificate of Origin 的认证可以由工具机械代签等同于git commit -s但认证责任始终属于人类。未披露的 AI 使用一旦事后被发现将被视为虚假陈述构成撤回该贡献的理由。仓库根目录的 AGENTS.md 同样规定了这条工作流提交使用$commitskillconventional commit 格式Pull Request 使用$prskill且归属信息必须使用真实的助手身份。总结一次合规 PR 的检查清单✅ 不在main上直接提交创建username/description特性分支✅ 用git status/git log/git diff --stat摸清改动全貌✅ 对受影响目标做一次 sanity build纯文档/ROMFS/submodule 改动可跳过✅ 标题符合type(scope): description≤72 字符可覆盖全部提交✅ 正文只有## Summary/## Problem/## Solution三节短小精悍、如实陈述测试✅ 需要时在 Summary 首行写fixes #N✅ 推送必要时-u后用gh pr create提交base 为main✅ AI 参与的内容在提交信息体中以Assisted-by: NAME:MODEL披露✅ 返回 PR URL。按此清单操作提交将被 CI 的 check_pr_title.py 与 check_commit_messages.py 顺利放行评审者也能快速抓住改动要点大幅缩短合入周期。赞分享嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载相关推荐Databend 提交与 Pull Request 规范实战指南从 Conventional Commits 到 AI 辅助协作Databend 提交与 Pull Request 规范实战指南从 Conventional Commits 到 AI 辅助协作 本文以 Databend 仓数据库数据分析向量数据库全文检索云原生AI 应用ECC Git 工作流规范Conventional Commits 提交约定与高质量 Pull Request 实战指南ECC Git 工作流规范Conventional Commits 提交约定与高质量 Pull Request 实战指南 导读 本文面向在 ECCEffic人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具用ARTEMIS Python SDK打通CI/CDpytest自动化手机测试完整实战示例用ARTEMIS Python SDK打通CI/CDpytest自动化手机测试完整实战示例 ARTEMIS 是一个把自然语言指令变成可靠 Android 自动人工智能AI AgentGUI 自动化测试MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PX4 Pull Request 实战指南：从分支创建到 Conventional Commits 合规的完整工作流
嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载本文以 PX4-Autopilot 仓库的 Pull Request 提交流程为纲完整还原一次 PR 从创建特性分支到提交并返回 PR 链接的七步标准操作并结合仓库内的 CI 校验脚本与贡献规范深入讲解 PR 标题、正文的格式要求以及 AI 辅助贡献的披露规则。读完本文你将能按 PX4 官方规范一次性提交格式正确、可被维护者快速评审的 Pull Request。背景PX4 的 PR 文化PX4-Autopilot 是安全攸关的飞行控制固件其代码合入有着比普通开源项目更严格的纪律。仓库 CONTRIBUTING.md 明确要求所有提交信息与 PR 标题遵循 Conventional Commits 格式并且强调PR 标题在 squash-merge 时会直接成为提交信息因此标题质量直接影响主线提交历史的可读性。与此配套仓库内有一套 CI 脚本专门校验提交信息与 PR 标题的合规性Tools/ci/check_pr_title.py校验 PR 标题是否符合type(scope): description格式不合法时输出建议修正的标题Tools/ci/check_commit_messages.py读取 GitHub API 返回的 PR 提交列表逐条检查阻塞性错误与建议性警告Tools/ci/conventional_commits.py上述两个脚本共用的解析与建议引擎定义了合法的 type 集合、scope 关键词映射与标题正则。本文描述的标准 PR 工作流共七步全部可由一个具备Bash、Read、Glob、Grep工具能力的 AI Agent 或开发者手动完成。第一步检查分支并创建特性分支PR 永远不应直接基于main提交。工作流的第一步是检查当前分支git branch --show-current如果当前位于main必须创建一个特性分支命名规范为username/description其中username来自当前 GitHub 账号可通过 GitHub CLI 获取gh api user --jq .login例如用户名为alice改动内容是添加 EKF2 高度融合超时则分支名为alice/ekf2-height-fusion-timeout。分支名中的 description 应当与后续 PR 标题的 description 保持一致使分支、提交与 PR 三者语义贯通。第二步收集改动上下文在撰写 PR 之前需要完整了解本次改动的范围。标准做法是执行以下四个检查# 1. 查看工作区是否有未提交改动 git status # 2. 查看当前分支相对 main 的所有提交 git log --oneline main..HEAD # 3. 查看相对 main 的改动统计变更了哪些文件、增删了多少行 git diff main...HEAD --stat # 4. 检查是否存在远程跟踪分支判断是否已推送过 git status -sb # 或 git rev-parse --abbrev-ref --symbolic-full-name {u}这三个检查回答了撰写 PR 时最关键的三个问题改了什么stat、有哪些提交log、是否需要推送remote tracking。这些信息决定了后续 PR 标题如何概括、正文如何描述问题与方案以及是否需要-u参数首次推送。第三步构建验证Sanity BuildPX4 是编译产物直接上机的项目提 PR 前必须确保改动能够编译通过。工作流要求构建一个该改动实际能影响到的目标改动类型应构建的目标固件改动驱动、模块、板级代码对应受影响的目标板例如make px4_fmu-v6x仅 POSIX / 仿真改动px4_sitlSITL 目标无法触及任何编译目标submodule 指针更新、文档、ROMFS跳过构建后一条规则很关键并非每个 PR 都需要构建。当git diff main...HEAD --stat显示改动仅涉及docs/、ROMFS/启动脚本、子模块指针等内容时直接跳过构建避免无意义的 CI 等待。若改动触及编译目标但构建失败必须在开 PR 之前修复所有构建错误。从源码结构看PX4 的 SITL 目标定义于 boards/px4/sitl而各板级目标位于 boards 目录下各自的*.px4board配置中构建系统入口为仓库根目录的 Makefile 与 CMakeLists.txt。第四步撰写 PR 标题——遵循 Conventional CommitsPR 标题是整个 PR 最重要的元数据因为它会成为 squash-merge 后的提交信息。格式为type(scope): description要求总长不超过 72 个字符必须覆盖该 PR 全部提交的整体改动而非只描述某一个 commit一旦通过 squash-merge 合入这个标题就是main上的提交信息。type 与 scope 的合法取值根据 CONTRIBUTING.md 与 Tools/ci/conventional_commits.py 中定义的CONVENTIONAL_TYPES合法的 type 为type含义feat新功能fix缺陷修复docs仅文档改动style格式、空白无代码逻辑变化refactor既非修 bug 也非新功能的代码重构perf性能改进test新增或修正测试build构建系统或外部依赖ciCI 配置与脚本chore不修改 src 或 test 文件的其他改动revert回滚之前的提交scope 标识受影响的模块、驱动、板子或领域。常用取值包括ekf2、mavlink、commander、navigator、sensors、drivers、mc_att_control、mc_pos_control、fw_att_control、vtol、actuators、battery、logger、param、simulation、ci、docs、build、uorb等。跨多个子系统的改动取主要影响的那个也可以直接看改动文件所在路径推断例如src/modules/ekf2/下的改动用ekf2src/drivers/imu/下的改动用drivers/imu。CI 如何校验标题Tools/ci/check_pr_title.py 在 CI 中对 PR 标题做正则匹配。其核心正则定义于 Tools/ci/conventional_commits.pyHEADER_PATTERN re.compile( r^( |.join(CONVENTIONAL_TYPES.keys()) r) r\(([a-zA-Z0-9_/\-\.])\) r(!)? r: (.{5,})$ )从中可以提取出 CI 的硬性规则type 必须是上表 11 个取值之一scope 必须存在且只能包含字母、数字、下划线、斜杠、连字符和点!可选放在冒号前表示 breaking change破坏性变更例如feat(ekf2)!: remove deprecated height fusion APIdescription 至少 5 个字符且必须以冒号空格分隔。当标题不合法时脚本还会尝试自动给出修正建议剥离[docs]这类方括号前缀、将旧式subsystem: description转换为新格式、甚至根据描述文本中的关键词推断 type 与 scope见suggest_title、suggest_type、suggest_scope。CI 会以 PR 评论的形式把建议标题贴出来。好的与坏的标题示例CONTRIBUTING.md 给出的范例feat(ekf2): add height fusion timeout fix(mavlink): correct BATTERY_STATUS_V2 parsing refactor(navigator): simplify RTL altitude logic ci(workflows): migrate to reusable workflows docs(ekf2): update tuning guide feat(boards/px4_fmu-v6x)!: remove deprecated driver API perf(mc_rate_control): reduce loop latency会被 CI 标记的糟糕标题fix # 太模糊缺 type/scope update # 太模糊 ekf2: fix something # 缺 type 前缀 apply suggestions from code review # 应 squash 进父提交 do make format # 应 squash 进父提交 WIP: trying something # 未就绪 oops # 无描述性第五步撰写 PR 正文——三段式极简结构PX4 的 PR 正文哲学是短到评审者一眼能看完——过长的描述反而没人读。正文必须且只能包含三个小节按顺序排列## Summary ## Problem ## Solution每节一两句话即可。硬性要求不要复述 diff不列变更文件清单不放代码片段不要提 CI不要重复标题已经说过的内容如果 PR 关闭某个 issue## Summary的第一行必须是fixes #N之后空一行再接摘要正文不设## Test plan小节不要模板化套话不要有任何 AI 归属声明如 Generated with Claude 之类的 footer详见后文 AI 披露一节。测试陈述的真实性原则这是 PX4 评审中非常看重的一条绝不声称没有发生的测试。正确的做法是主动询问用户实际运行过什么SITL、台架测试还是真机飞行如实报告测试内容没有测试就明确说未测试。结合 CONTRIBUTING.md 的测试要求新功能必须尽量附带单元测试和/或集成测试bug 修复尽量附带回归测试无法自动化测试的硬件相关改动应提供台架或飞行测试证据如 Flight Review 日志链接。PX4 是安全攸关软件评审者会在批准前核对测试或测试证据是否存在——因此正文里一句诚实的未测试远好于一段虚假的测试描述。第六步推送并创建 PR改动就绪后若分支尚未推送过使用-u设置上游并推送git push -u origin username/description然后通过 GitHub CLI 创建 PRgh pr create默认基准分支base为main除非用户明确指定其他目标分支。若用户在发起任务时提供了额外参数如目标分支或描述将其作为上下文用于完善标题与正文。第七步返回 PR 链接创建成功后将gh pr create输出的 PR URL 返回给用户整个流程结束。附AI 辅助贡献的披露规则该 PR 工作流在设计时明确假定用户人类是作者。两条核心红线不得添加Co-Authored-By署名也不得在 PR 正文添加 Generated with Claude 之类的 footerAI 使用情况必须通过提交信息的 trailer 披露而不是放在 PR 正文里。披露格式为提交信息体中的 trailerAssisted-by: NAME:MODEL其中NAME是工具名、MODEL是具体模型名例如Assisted-by: Claude:claude-fable-5 Assisted-by: Copilot:gpt-5这条规则与仓库的 AI 辅助贡献政策 docs/en/contribute/ai_assistants.md 一致AI 工具永远不会是作者或合著者绝不出现于Signed-off-by标签中人类提交者必须理解并能捍卫提交的每一行。Signed-off-by仍是人类作者对 Developer Certificate of Origin 的认证可以由工具机械代签等同于git commit -s但认证责任始终属于人类。未披露的 AI 使用一旦事后被发现将被视为虚假陈述构成撤回该贡献的理由。仓库根目录的 AGENTS.md 同样规定了这条工作流提交使用$commitskillconventional commit 格式Pull Request 使用$prskill且归属信息必须使用真实的助手身份。总结一次合规 PR 的检查清单✅ 不在main上直接提交创建username/description特性分支✅ 用git status/git log/git diff --stat摸清改动全貌✅ 对受影响目标做一次 sanity build纯文档/ROMFS/submodule 改动可跳过✅ 标题符合type(scope): description≤72 字符可覆盖全部提交✅ 正文只有## Summary/## Problem/## Solution三节短小精悍、如实陈述测试✅ 需要时在 Summary 首行写fixes #N✅ 推送必要时-u后用gh pr create提交base 为main✅ AI 参与的内容在提交信息体中以Assisted-by: NAME:MODEL披露✅ 返回 PR URL。按此清单操作提交将被 CI 的 check_pr_title.py 与 check_commit_messages.py 顺利放行评审者也能快速抓住改动要点大幅缩短合入周期。赞分享嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载相关推荐Databend 提交与 Pull Request 规范实战指南从 Conventional Commits 到 AI 辅助协作Databend 提交与 Pull Request 规范实战指南从 Conventional Commits 到 AI 辅助协作 本文以 Databend 仓数据库数据分析向量数据库全文检索云原生AI 应用ECC Git 工作流规范Conventional Commits 提交约定与高质量 Pull Request 实战指南ECC Git 工作流规范Conventional Commits 提交约定与高质量 Pull Request 实战指南 导读 本文面向在 ECCEffic人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具用ARTEMIS Python SDK打通CI/CDpytest自动化手机测试完整实战示例用ARTEMIS Python SDK打通CI/CDpytest自动化手机测试完整实战示例 ARTEMIS 是一个把自然语言指令变成可靠 Android 自动人工智能AI AgentGUI 自动化测试MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考