企业官网建设流程全解析

MemOS 提交规范速成指南：Conventional Commits 提交信息一次写对

【免费下载链接】MemOSSelf-evolving memory OS for LLM & AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址: https://gitcode.com/gh_mirrors/memos/MemOS

改完 MemOS 的第一个功能，测试跑绿了，正要按下 commit 却卡住——提交信息怎么写，才能让评审秒懂意图、CI 一次通过？MemOS 是给 LLM 和 AI Agent 用的记忆操作系统，它的贡献流程要求所有提交信息遵循 Conventional Commits 提交规范。没做过开源贡献也别慌，这篇文章带你从选类型到提 PR 走完全程：MemOS 提交信息怎么写，3 步就够。

30 秒搞懂：Conventional Commits 到底解决什么？

Conventional Commits 是一套轻量的提交信息命名约定：每条 commit 用「固定类型前缀 + 简短描述」开头，类型来自一个封闭集合。可以把 type 前缀想象成快递面单上的类目栏——评审者、自动化工具、git log 过滤器都能顺着它分拣和检索。

MemOS 强制它，图的是三个实打实的收益：feat/fix能自动归类、直接喂给 CHANGELOG 生成；CI 和 pre-commit 钩子能统一校验（pyproject.toml 里就声明了 pre-commit 依赖，提交时机就被卡住）；git log --grep检索立刻好用。规范出处在 CONTRIBUTING.md 与 commit_guidelines.md，两处的 8 种类型定义完全一致。

如何快速选对提交类型？

官方定义的 8 种类型，基本和「你改了什么」一一对应。下表里的示例与场景都取自仓库真实语境：

最容易混的一对是style与refactor：两者都不改行为，但 style 只管格式（空白、缩进、换行），refactor 动的是代码组织层面的结构。凡沾了逻辑改动，一律不许挂style。第二个常见坑：同一个提交里既改代码又升依赖——这是把 feat 和 chore 两个逻辑单元装进一个包裹，评审时很难拆账，分开提更干净。

3 步写出规范 commit message

第一步，套模板。格式是<type>: <description>：第一行一句说清干了什么，type 从上面 8 种里选，冒号后带空格。

第二步，用祈使语气。description 用 add、fix、update，而不是过去时的 added、fixed。CONTRIBUTING.md 对这一点有明确要求——「prevent memory leak」可以，「prevented memory leak」不行。祈使语气的潜台词是「这条提交做了什么」，读起来像指令，不像流水账。

第三步，大改动补 body，写「为什么」。diff 本身已经交代了「改了什么」，body 的价值在于交代动机、取舍和影响面；改个错别字这种小改动，body 可省。

Conventional Commits 怎么写最不容易错？照着官方风格示例练手感即可，下面四条对应的都是仓库里真实存在的模块（MemScheduler、MemCube 等）：

feat: add Redis Streams backend for MemScheduler fix: prevent memory leak in MemCube cleanup docs: clarify MemCube vs MemReader in core concepts refactor: extract retry logic into shared helper

把这四条和上表的 8 种类型对照着看，就能形成「场景 → 措辞」的映射，这也是 commit message 最佳实践的核心：先想清楚改了哪个模块的什么行为，再查表定类型，最后用祈使语气一句话收尾。

改动类型对号入座：这次改动该挂什么类型？

MemOS 提交信息怎么写，最省脑子的办法是「按改动区域对号入座」：

从本地到 PR：提交流程怎么走？

提交信息只是前半程，另一半是提交流程。下面这条链路就是 development_workflow.md 推荐的最小闭环：

git checkout dev && git fetch upstream && git pull upstream dev git checkout -b feat/your-feature-name make test git fetch upstream && git rebase upstream/dev git commit -m "feat: add your feature" git push origin feat/your-feature-name # 向上游提 PR：base 分支选 dev，不要选 main

⚠️PR 的 base 分支必须是dev，对着main提会被要求 retarget。同时把 CONTRIBUTING.md 里 Good PR 清单记牢：一个 PR 只含一个逻辑改动，别夹带不相关的修复；新代码带测试，Bug 修复附回归测试；公开 API 写 docstring；非平凡改动关联 issue（Closes #123）；CI 不绿，PR 不合并。

红线清单：提交信息最常踩哪些坑？

• 过去时态❌fix: corrected typo in parser✅fix: correct typo in parser
• 描述含糊❌fix: update code✅fix: prevent memory leak in MemCube cleanup
• style 里塞逻辑——只要动了行为，哪怕一行，就不是格式问题，降级到refactor或fix
• 一次提交跨类型——代码 + 文档 + 依赖一起提，拆成三个各自单类型的提交
• 大改动 body 只复述 what——动机、取舍、影响面一个没写，等于没写

提交前自检清单

1. 首行是否为<type>: <description>，type 在 8 种之内、描述是祈使语气？
2. 这个提交是不是只包含一个逻辑改动？
3. 大改动的 body 里有没有解释「为什么」？
4. 分支是否已 rebase 到最新 dev，make test是否通过？
5. PR 目标分支是不是 dev，是否关联了对应 issue？

提交信息就是代码的面单类目栏——写对了，你的开源贡献之路就已经走顺了一大半。

【免费下载链接】MemOSSelf-evolving memory OS for LLM & AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址: https://gitcode.com/gh_mirrors/memos/MemOS