Git 提交规范 适用场景 - 编写 commit message - 判断本次改动应归类为 、 、 等哪一类 - 整理提交边界，避免一个提交塞入多类无关改动 - 提交前做最基本的自检 不适用场景 - 讨论具体业务实现方案 - 修改 Git 历史或做高风险 Git 操作 - 只是创建分支，但不涉及提交规范本身 快速指导 1. 这个 skill 关注的是“提交如何表达改动意图”，不是 Git 命令大全。 2. commit message 优先表达改动性质和目的，常见类型包括： - ：新增能力 - ：修复问题 - ：重构但不改外部行为 - ：性能优化 - ：测试补充或调整 - ：文档变更 - ：构建、配置、工具链维护 3. 提交信息格式保持简洁稳定，例如： 4. 一个提交只表达一类主要意图；如果混入多个独立目的，优先拆分提交。 5. 提交前先做最小自检：改动范围是否聚焦、是否包含敏感信息、是否通过必要验证。 6. 高风险历史整理操作不应作为默认建议写进主 skill；如确有需要，应按具体场景单独判断。 高信号规则 - commit message 的核心是让评审者快速理解“这次改动为什么存在” - 类型选择要服务于改动意图，不要机械套用 - 提交边界清楚，比 message 写得花更重要 - Issue 编号、范围标记等信息应服从团队约定，但不要盖过主语义 关键陷阱 - 一个提交同…