代码提交流程 ======================= .. _commits: 提交规范 ~~~~~~~ #. 提交内容需保持逻辑独立性，避免在单次提交中修复无关问题。 #. 避免冗余提交，若提交2修正了提交1的内容，请使用变基操作合并它们。 #. 提交信息需完整说明非显而易见的内容 #. 禁止在单次提交中同时修改、重命名及移动代码。应拆分为独立提交，例如先提交重命名操作，再提交代码修改。 #. 若代码变更涉及行为修改或新增功能，需在独立提交中添加相关文档更新，并确保使用相同的工单编号。 #. 提交信息需符合标准格式（参考本节后续示例）： * 首行为有意义的简短主题（不超过50字符），后接空行 * 命名规范：使用子系统前缀（如 **"规则解析：修复foobar"**）。不确定时可参考历史提交记录 * 描述内容每行约72字符换行 #. 每个提交应确保可独立编译，从最旧提交开始逐级验证PR中的每个提交均可成功构建 #. 提交作者信息格式："姓名 <邮箱@示例.com>" 推荐使用Git提交模板： ``git config commit.template /path/to/suricata/git-template/commit-template.txt`` 该模板列出了帮助描述上下文和包含必要信息的条目。我们保留未来严格执行该模板的权利： 提交必须包含的信息（如适用）： #. 修复的工单，例如："修复Bug #123" #. 解决的编译器警告 #. 修复的Coverity Scan问题 #. 解决的静态分析器错误（cppcheck/scan-build等） .. note:: 不确定时，请参考相同模块的git历史记录。以下是规范的`提交信息示例 `_:: pcap/file: 标准化文件时间戳 将过早的时间戳规范化为纪元时间。 漏洞: #6240. .. _pull-requests-criteria: 拉取请求规范 ~~~~~~~~~~~~ GitHub拉取请求实质是指向您代码库分支的指针。我们使用GitHub提供的评审界面。 #. 每个分支仅能用于单个PR #. 分支在创建PR后不应再更新 #. PR必须包含清晰描述（如关联工单需附问题追踪链接） #. 迭代式PR需链接前序版本 #. 迭代式PR需说明与前版的变更差异 #. 关联解决的工单链接 #. 提交PR后，请将对应工单状态更新为``评审中`` #. PR会自动通过GitHub Actions进行测试(https://github.com/OISF/suricata/blob/master/.github/workflows/builds.yml)，构建失败的PR将不予受理并应立即关闭 #. 涉及功能变更或新增的PR必须包含文档更新提交 测试与质量保证 ~~~~~~~~~~~~ 新增功能应尽可能便于质量验证。 #. 添加``suricata-verify``测试用例，参考https://github.com/OISF/suricata-verify #. 若无法通过verify测试，需添加单元测试 #. 提供能复现问题的pcap文件，尽量精简至仅包含能演示问题的最小数据包集合 #. 若新增关键字或现有关键字新选项，需提供示例规则