代码提交流程¶

提交规范¶

提交内容需保持逻辑独立性，避免在单次提交中修复无关问题。
避免冗余提交，若提交2修正了提交1的内容，请使用变基操作合并它们。
提交信息需完整说明非显而易见的内容
禁止在单次提交中同时修改、重命名及移动代码。应拆分为独立提交，例如先提交重命名操作，再提交代码修改。
若代码变更涉及行为修改或新增功能，需在独立提交中添加相关文档更新，并确保使用相同的工单编号。
提交信息需符合标准格式（参考本节后续示例）：
- 首行为有意义的简短主题（不超过50字符），后接空行
- 命名规范：使用子系统前缀（如 "规则解析：修复foobar"）。不确定时可参考历史提交记录
- 描述内容每行约72字符换行
每个提交应确保可独立编译，从最旧提交开始逐级验证PR中的每个提交均可成功构建
提交作者信息格式："姓名 <邮箱@示例.com>"

推荐使用Git提交模板： git config commit.template /path/to/suricata/git-template/commit-template.txt 该模板列出了帮助描述上下文和包含必要信息的条目。我们保留未来严格执行该模板的权利：

提交必须包含的信息（如适用）：

Note

不确定时，请参考相同模块的git历史记录。以下是规范的`提交信息示例 <https://github.com/OISF/suricata/commit/33fca4d4db112b75ffa22eb2e6f14f038cbcc1f9>`_:

pcap/file: 标准化文件时间戳

将过早的时间戳规范化为纪元时间。

漏洞: #6240.

GitHub拉取请求实质是指向您代码库分支的指针。我们使用GitHub提供的评审界面。

每个分支仅能用于单个PR
分支在创建PR后不应再更新
PR必须包含清晰描述（如关联工单需附问题追踪链接）
迭代式PR需链接前序版本
迭代式PR需说明与前版的变更差异
关联解决的工单链接
提交PR后，请将对应工单状态更新为``评审中``
PR会自动通过GitHub Actions进行测试(https://github.com/OISF/suricata/blob/master/.github/workflows/builds.yml)，构建失败的PR将不予受理并应立即关闭
涉及功能变更或新增的PR必须包含文档更新提交

新增功能应尽可能便于质量验证。