MemOS 提交规范一次通过 PR 评审的三层消息公式【免费下载链接】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/MemOSMemOS 提交规范建立在 Conventional Commits 之上本文带你以新贡献者视角过一遍 8 种提交类型、commit message 模板与直到提 PR 的完整流程让每次提交可检索、评审一次通过。先回答为什么规范化提交解决三个真实问题刚给 MemOS 提代码时很多人觉得 commit message 是随手一行字。项目却要求每条提交都遵循 Conventional Commits 约定规则见 commit_guidelines.md。这不是形式主义前缀里的类型标签能直接换来三件事变更日志自动归档。semantic-release 一类工具会按类型把feat、fix自动归类、驱动版本号演进。MemOS 的 Python 包版本记录在 pyproject.toml当前 2.0.x 线发布说明就是按提交历史语义生成的——类型标错条目就归错档。PR 评审提速。评审者扫一眼类型前缀就知道这次是加功能、修缺陷还是动依赖评估影响面的范围立刻收敛写update code这类模糊描述评审只能逐行 diff 猜意图来回沟通成本翻倍。历史可检索。前缀统一后git log --grep^feat一次出结果。项目自身的提交就是活样本例如docs: highlight DeepSeek Harness integrations in README (#2262)类型前缀之外还附带 PR 编号方便按编号回溯。速查8 种提交类型各管什么MemOS 只承认 8 种类型。写提交前先回答这次改动干了什么再选类型类型适用场景边界提示feat引入面向用户的新能力典型如给 src/memos/mem_scheduler/ 增加新后端fix纠正不符合预期的行为要说明修的是哪个模块的什么行为docs纯文档改动只动 README 与 docs/不夹带源码style纯格式化清理只动空白、缩进、换行禁止包含任何逻辑变更refactor行为不变的结构重组移动函数、拆分模块、调整类组织前后行为一致test新增或更新测试用例只涉及 tests/ 下的测试文件chore与功能无关的维护工作升级依赖、维护构建脚本常围绕 pyproject.tomlciCI/CD 或工作流变更流水线配置与钩子安装如 Makefile 中make install挂接的 pre-commit hooks唯一容易判错的一对style与refactor两者共同点是行为不变差别在动作层级style作用在形式层空格、换行、引号风格这类排版变化。只要动了一行逻辑就不能标style否则评审会质疑标签真实性。refactor作用在组织层把重试逻辑从三处抽到一个共享 helper、把函数挪进公共模块——结构变了输入输出不变。一个判断口径需要改动代码之间的调用关系或模块边界就是refactor只改动长什么样才是style。一条标准消息的三层公式CONTRIBUTING.md 给出的模板分三层feat: add Redis Streams backend for MemScheduler 调度器的任务投递需要跨进程重启存活内存队列在重启后全量丢失 故选用 Redis Streams 作为持久化通道恢复后可重放旧任务。第一层类型标签type:取速查表 8 种之一冒号后必须留一个空格。第二层简短描述唯一必填的句子要求祈使语气——用add、fix、update不用过去时的added、fixed。祈使句读起来像指令描述句读起来像事后汇报混用时 git 历史会显得节奏断裂这也是新手首次 PR 最常见的 review 意见。第三层body 与 footer均可选较大的改动必须补 body而 body 要写**为什么**——动机、取舍、被放弃的方案。是什么不用写diff 已经展示了每一行改动body 里复述一遍等于让评审者读两遍。正例反例对照评审一次通过和被打回的差别正例fix: prevent memory leak in MemCube cleanup 释放阶段未清理激活记忆缓存导致常驻内存持续增长 本次在清理入口补充释放钩子。类型、模块、行为、原因四要素齐全评审不用追问。反例一时态错加描述空fix: updated the scheduler codeupdated是过去时scheduler code没说清修了什么行为评审只能在评论区追问白白多一轮。反例二两种类型捆在一起chore: upgrade dependencies and fix the viewer crash依赖升级和崩溃修复各属chore与fix捆在一条提交里两边都不合规。项目要求每个 PR 只承载一个逻辑改动拆成两次提交、两个 PR 才是正确姿势。自查提交前必查的六件事每次git commit之前花 30 秒过一遍对应 CONTRIBUTING.md 的 Good PR 清单单一类型、单一逻辑单元提交不捆绑无关改动一个 PR 只包含一个逻辑改动。祈使语气开头描述以add/fix/update起笔无过去时、无人称主语。具体到模块与行为一句话能看出改了什么拒绝update codemisc fixes。大改动带为什么body重构、跨模块调整在 body 说明动机与取舍公开 API 补齐 docstring。新代码带测试新功能附测试缺陷修复带回归测试用make test全量验证。关联 issue 且 CI 为绿非平凡改动在 PR 描述引用 issueCloses #123检查项全绿再提交。流程速览从同步上游到向 dev 提 PR官方开发流程写在 development_workflow.md以下命令按序执行即是完整闭环# 0. 首次参与克隆仓库并配置 fork 远端 git clone https://gitcode.com/gh_mirrors/memos/MemOS # 1. 同步上游 dev 分支 git checkout dev git fetch upstream git pull upstream dev git push origin dev # 2. 切功能分支分支名与提交类型呼应 git checkout -b feat/descriptive-name # 3. 编写代码与测试跑测试套件 make test # 4. 提交前 rebase 到最新 dev保持提交线干净 git fetch upstream git rebase upstream/dev # 5. 按规范提交并推送到 fork git commit -m feat: add Redis Streams backend for MemScheduler git push origin feat/descriptive-name最后一步最容易踩坑 ⚠️PR 的目标分支必须是上游仓库的dev而不是main官方明确说明指向main的 PR 会被要求改投。合并默认走 squash and merge提交切得越干净最终留在主干的记录就越可读。一句话总结类型标签 祈使描述 写为什么的 body就是 MemOS 提交规范的全部骨架。建议你下一次提交时先对照 8 种类型速查表想清楚类型再敲git commit——评审少一轮来回合入就快一步。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
MemOS 提交规范一次通过 PR 评审的三层消息公式【免费下载链接】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/MemOSMemOS 提交规范建立在 Conventional Commits 之上本文带你以新贡献者视角过一遍 8 种提交类型、commit message 模板与直到提 PR 的完整流程让每次提交可检索、评审一次通过。先回答为什么规范化提交解决三个真实问题刚给 MemOS 提代码时很多人觉得 commit message 是随手一行字。项目却要求每条提交都遵循 Conventional Commits 约定规则见 commit_guidelines.md。这不是形式主义前缀里的类型标签能直接换来三件事变更日志自动归档。semantic-release 一类工具会按类型把feat、fix自动归类、驱动版本号演进。MemOS 的 Python 包版本记录在 pyproject.toml当前 2.0.x 线发布说明就是按提交历史语义生成的——类型标错条目就归错档。PR 评审提速。评审者扫一眼类型前缀就知道这次是加功能、修缺陷还是动依赖评估影响面的范围立刻收敛写update code这类模糊描述评审只能逐行 diff 猜意图来回沟通成本翻倍。历史可检索。前缀统一后git log --grep^feat一次出结果。项目自身的提交就是活样本例如docs: highlight DeepSeek Harness integrations in README (#2262)类型前缀之外还附带 PR 编号方便按编号回溯。速查8 种提交类型各管什么MemOS 只承认 8 种类型。写提交前先回答这次改动干了什么再选类型类型适用场景边界提示feat引入面向用户的新能力典型如给 src/memos/mem_scheduler/ 增加新后端fix纠正不符合预期的行为要说明修的是哪个模块的什么行为docs纯文档改动只动 README 与 docs/不夹带源码style纯格式化清理只动空白、缩进、换行禁止包含任何逻辑变更refactor行为不变的结构重组移动函数、拆分模块、调整类组织前后行为一致test新增或更新测试用例只涉及 tests/ 下的测试文件chore与功能无关的维护工作升级依赖、维护构建脚本常围绕 pyproject.tomlciCI/CD 或工作流变更流水线配置与钩子安装如 Makefile 中make install挂接的 pre-commit hooks唯一容易判错的一对style与refactor两者共同点是行为不变差别在动作层级style作用在形式层空格、换行、引号风格这类排版变化。只要动了一行逻辑就不能标style否则评审会质疑标签真实性。refactor作用在组织层把重试逻辑从三处抽到一个共享 helper、把函数挪进公共模块——结构变了输入输出不变。一个判断口径需要改动代码之间的调用关系或模块边界就是refactor只改动长什么样才是style。一条标准消息的三层公式CONTRIBUTING.md 给出的模板分三层feat: add Redis Streams backend for MemScheduler 调度器的任务投递需要跨进程重启存活内存队列在重启后全量丢失 故选用 Redis Streams 作为持久化通道恢复后可重放旧任务。第一层类型标签type:取速查表 8 种之一冒号后必须留一个空格。第二层简短描述唯一必填的句子要求祈使语气——用add、fix、update不用过去时的added、fixed。祈使句读起来像指令描述句读起来像事后汇报混用时 git 历史会显得节奏断裂这也是新手首次 PR 最常见的 review 意见。第三层body 与 footer均可选较大的改动必须补 body而 body 要写**为什么**——动机、取舍、被放弃的方案。是什么不用写diff 已经展示了每一行改动body 里复述一遍等于让评审者读两遍。正例反例对照评审一次通过和被打回的差别正例fix: prevent memory leak in MemCube cleanup 释放阶段未清理激活记忆缓存导致常驻内存持续增长 本次在清理入口补充释放钩子。类型、模块、行为、原因四要素齐全评审不用追问。反例一时态错加描述空fix: updated the scheduler codeupdated是过去时scheduler code没说清修了什么行为评审只能在评论区追问白白多一轮。反例二两种类型捆在一起chore: upgrade dependencies and fix the viewer crash依赖升级和崩溃修复各属chore与fix捆在一条提交里两边都不合规。项目要求每个 PR 只承载一个逻辑改动拆成两次提交、两个 PR 才是正确姿势。自查提交前必查的六件事每次git commit之前花 30 秒过一遍对应 CONTRIBUTING.md 的 Good PR 清单单一类型、单一逻辑单元提交不捆绑无关改动一个 PR 只包含一个逻辑改动。祈使语气开头描述以add/fix/update起笔无过去时、无人称主语。具体到模块与行为一句话能看出改了什么拒绝update codemisc fixes。大改动带为什么body重构、跨模块调整在 body 说明动机与取舍公开 API 补齐 docstring。新代码带测试新功能附测试缺陷修复带回归测试用make test全量验证。关联 issue 且 CI 为绿非平凡改动在 PR 描述引用 issueCloses #123检查项全绿再提交。流程速览从同步上游到向 dev 提 PR官方开发流程写在 development_workflow.md以下命令按序执行即是完整闭环# 0. 首次参与克隆仓库并配置 fork 远端 git clone https://gitcode.com/gh_mirrors/memos/MemOS # 1. 同步上游 dev 分支 git checkout dev git fetch upstream git pull upstream dev git push origin dev # 2. 切功能分支分支名与提交类型呼应 git checkout -b feat/descriptive-name # 3. 编写代码与测试跑测试套件 make test # 4. 提交前 rebase 到最新 dev保持提交线干净 git fetch upstream git rebase upstream/dev # 5. 按规范提交并推送到 fork git commit -m feat: add Redis Streams backend for MemScheduler git push origin feat/descriptive-name最后一步最容易踩坑 ⚠️PR 的目标分支必须是上游仓库的dev而不是main官方明确说明指向main的 PR 会被要求改投。合并默认走 squash and merge提交切得越干净最终留在主干的记录就越可读。一句话总结类型标签 祈使描述 写为什么的 body就是 MemOS 提交规范的全部骨架。建议你下一次提交时先对照 8 种类型速查表想清楚类型再敲git commit——评审少一轮来回合入就快一步。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
