无需登录 数据私有 本地保存

Git 提交信息生成器 - 遵循约定式提交自动补全

Git 开发工具 Git 提交信息 生成 约定式
51
0
0
0
请选择提交类型
请输入提交描述
建议不超过50字符，上限72字符。使用祈使语气，首字母小写（英文）。
🔗 Closes # 🔧 Fixes # 📎 Refs # ⚠️ BREAKING CHANGE 👀 Reviewed-by 🤝 Co-authored-by
实时预览
git commit -m 请选择类型并输入描述...
总字符数：0
历史记录
暂无历史记录，生成的提交信息将自动保存在这里
约定式提交（Conventional Commits）知识库
什么是约定式提交？

约定式提交是一种轻量级的提交信息规范，它明确规定了提交信息的结构，使得提交历史更加可读，并且便于自动化工具（如语义化版本发布、CHANGELOG生成）进行处理。其基本格式为：type(scope): description。

提交类型详解
  • feat — 新功能（对应语义化版本的 MINOR）
  • fix — 修复Bug（对应语义化版本的 PATCH）
  • docs — 仅文档变更（README、注释等）
  • style — 不影响代码逻辑的格式变更（空格、缩进、分号等）
  • refactor — 既不修复Bug也不添加功能的代码重构
  • perf — 提升性能的代码变更
  • test — 添加或修改测试代码
  • build — 影响构建系统或外部依赖的变更
  • ci — CI/CD 配置文件和脚本的变更
  • chore — 不修改代码或测试的杂项任务
  • revert — 回滚之前的提交
常见问题

Git官方建议标题行不超过50个字符，约定式提交规范建议不超过72个字符。过长的标题在git log --oneline中会被截断，影响可读性。本工具会在超过50字符时给出温和提醒。

有两种方式：(1) 在类型后添加 !，如 feat!: 重构API；(2) 在脚注中添加 BREAKING CHANGE: 前缀。推荐同时使用两种方式以确保工具链兼容性。

feat类型对应MINOR版本号递增，fix类型对应PATCH版本号递增，带有BREAKING CHANGE的提交对应MAJOR版本号递增。自动化工具（如semantic-release）可以据此自动发布版本。

建议使用commitlint + husky在提交时自动校验提交信息格式，配合本工具降低上手门槛。同时在团队文档中明确规范，并利用CI/CD自动生成CHANGELOG，让团队看到规范带来的实际价值。

类型（type）推荐使用英文以保持与工具链兼容，描述部分可以根据团队习惯选择中文或英文。关键是保持团队内部一致。国际化开源项目建议使用英文。

使用约定式提交可以让Git历史更加清晰易读，方便code review和版本回溯。更重要的是它能与自动化工具链（如semantic-release、standard-version）无缝集成，实现自动版本发布和CHANGELOG生成，大幅提升开发效率。
最佳实践
  • 使用祈使语气，如"添加"而非"添加了"
  • 标题行首字母小写（英文描述时）
  • 标题行结尾不加句号
  • 一个提交只做一件事，保持原子性
  • body部分解释为什么要做这个变更
  • 善用脚注关联Issue和PR
  • 在CI中配置commitlint自动校验格式
🔧 相关工具