commit message模糊导致分支污染，因其切断意图传递链：type缺失使ci无法分类生成changelog，scope缺失致难以定位模块变更，subject笼统令git log不可读，body为空则缺失排查依据。
分支污染不是代码问题，是协作信号混乱的结果——Commit Message写得模糊，分支合并就容易失控。
commit -m 里写 “fix bug” 为什么会让 develop 分支变脏
这种提交看似无害，实则切断了分支意图的传递链。当 git merge feat/login 进入 develop 时，如果其中混着多个 fix bug、update 类提交，CI 工具无法区分哪些是功能配套改动、哪些是临时调试残留，更没法自动过滤出真正该进 release 的变更。
- 类型缺失 → 工具无法按
feat/fix分类生成 CHANGELOG - scope 缺失 → 合并后无法快速定位某模块（如
auth）的全部相关提交 - subject 过于笼统 →
git log --oneline看不到实质内容，review 时只能翻 diff - body 为空 → 后续排查“为什么这里要加空校验”时，找不到上下文依据
feat/xxx 分支里必须只出现 feat 和 refactor 类型提交
功能分支不是垃圾桶，它的存在意义就是承载单一目标的完整实现路径。一旦允许 fix 或 docs 混入，就等于默认接受“这个分支还顺手修了别的东西”，后续合并到 develop 时，其他团队成员根本无法判断：这是功能自带的修复，还是意外带入的无关改动。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 新功能开发中自然产生的重构，用
refactor(auth): extract token validation logic - 配套的文档更新，用
docs: add login flow diagram to README.md，且仅限该功能范围 - 绝对禁止在
feat/分支里提交fix(api): handle timeout—— 这属于develop或hotfix/的职责 - CI 可配置检查：拒绝合并含非
feat/refactor/test类型的 PR 到feat/分支
hotfix/xxx 合并后，develop 分支必须同步该 fix 提交
热修复从 main 拉出、修复后合并回 main，这没问题；但若不同时合并进 develop，就会造成“线上已修、开发环境仍复现”的分裂状态。而同步的关键，是 commit message 必须保持一致 —— 不是复制粘贴，而是复用同一 hash 的原始提交。
- 执行
git cherry-pick <hotfix-commit-hash></hotfix-commit-hash>到develop，而非重新git commit -m - 原始提交已是
fix(auth): prevent JWT decode crash on malformed token，cherry-pick 后无需改写 - 若手动重提，type 写成
chore或漏掉 scope，CI 自动化比对会认为这是“另一处修改”，导致重复修复或漏测 - 脚注
Fixes #1234必须保留，否则 issue 状态不会自动关闭
CI 阶段如何用 commit message 拦住污染行为
人工 review 很难盯住每条提交，但机器可以。关键不是“有没有 commit message”，而是“message 是否携带可验证的分支语义”。比如 feat(payment) 提交出现在 hotfix/ 分支，就是明确违规。
- Git Hook 或 CI 脚本检查：提取当前分支名前缀（
feat/、hotfix/），匹配 header 中的type -
hotfix/分支只允许fix、test、docs（仅限修复说明），拒绝feat、perf -
release/分支只允许docs、chore、fix（仅限发布相关修复），拒绝任何feat或refactor - 错误示例：
git push被拒时返回ERROR: commit 'feat(ui): add dark mode toggle' not allowed in hotfix/v2.1.3
真正难的不是写清楚一条 commit，而是让每条 commit 都成为分支意图的锚点——它得能回答“谁在什么分支上、为什么改这里、改完去哪”。漏掉任意一环，分支就可能在下次 merge 时悄悄污染。
