Git 提交信息模板

可在终端和编辑器中展开的可复用 Conventional Commits 风格、PR 就绪的信息模板。

模板类别概述

一致的提交信息使仓库历史可读、支持自动 changelog 并加快代码审查——但每次手动输入结构良好的 Conventional Commit 足够乏味，以至于大多数开发者退回到一行式摘要。文本扩展器通过将简短触发词变成已布置好类型、scope、摘要、正文和页脚的完整提交骨架来解决这个问题，于是你填写细节而非记住格式。由于 Lightning Assist 在系统级运行——包括大多数提交实际发生的终端以及 VS Code 的提交框——无论你从命令行、IDE 还是 Git GUI 提交，同样的模板都有效。当你在调试中途双手离开键盘时，Push-to-Talk 语音甚至可以口述较长的正文段落。

何时使用这些模板

在每次提交时使用提交信息模板，但它们在以后才重要的提交上回报最大：你将重访的错误修复、影响其他团队的 breaking changes，以及任何从历史自动生成发布或 changelog 的仓库中的提交。如果你的项目使用 Conventional Commits、semantic-release 或任何 changelog 自动化，一致的骨架不只是整洁——它正是让 tooling 能够工作的根本。即使在单人项目上，以一致格式编写的可读 git log 在你 bisect 一个回归或试图回忆某个更改为何在六个月前做出时也能节省实际时间。

此类别中的示例模板

  • Conventional Commit 骨架：类型、可选 scope、摘要、正文以及带 ticket 引用的页脚。
  • 带错误上下文的 fix 提交：什么坏了、修复以及它关闭的 issue。
  • 破坏性变更提交：变更加上为发布 tooling 明确标记的 BREAKING CHANGE 页脚。

实践中的示例模板

Conventional Commit 骨架

遵循为自动版本控制和 changelog 工具提供动力的 Conventional Commits 规范的、用于任何提交的日常模板。结构是：类型（feat、fix、chore、docs、refactor、test 等）、括号中的可选 scope、约五十字符以内的简洁祈使式摘要、一个空行、然后是解释为什么的正文，以及用于 ticket 引用的页脚。把它放在像 ;cc 的简短触发词上，使它在你写信息之前就在终端中展开。每次填写一致的骨架正是让 git log 在数月后真正有用的原因，也是一个能自动生成 changelog 的发布工具与一个不能的工具之间的区别。

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

带错误上下文的 fix 提交

错误修复提交是未来的你最需要理解的，因此它们值得比"fix bug"更多。捕捉三件事：什么坏了（可观察的症状）、修复做了什么，以及它关闭哪个 issue 以便追踪器自动更新。"Closes #"页脚正是将提交链接到你的 issue 追踪器并在大多数平台上于 merge 时关闭 ticket 的东西。把它放在像 ;fix 的触发词上。当你深陷调试会话并想用平实语言记录根本原因时，Push-to-Talk 语音让你口述正文而不打断心流，而 AI Enhance 可以把冗长的口述解释收紧成干净的段落。

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

破坏性变更提交

当一个提交更改了 API、配置格式或其他代码所依赖的任何契约时，必须明确标记破坏性变更，以便发布 tooling 触发大版本跃升且 changelog 警告用户。Conventional Commits 标准正是为此使用 BREAKING CHANGE: 页脚（或类型后的 !）。说明什么坏了，并且最关键的是，使用者必须做什么才能迁移——没有迁移说明的破坏性变更只会变成一波支持问题。把它放在像 ;ccbreak 的刻意触发词上，使你只在确实有此意图时才用它，因为错误标记破坏性变更比不标记更糟。

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

如何开始

从一个带有类型、scope、摘要、正文和 ticket 占位符的简短触发词（如 ;cc）上的通用 Conventional Commit 骨架开始。添加一个预填了 fix 类型和"Closes #"页脚的 ;fix 变体，以及一个带有 BREAKING CHANGE 页脚、用于罕见但重要的破坏性提交的 ;ccbreak 变体。在你的终端或编辑器的提交框中输入触发词，它会在你输入时内联展开——无需热键，并且在两者中表现一致，因为展开是系统级的。当骨架变得自然后，添加 PR 描述和代码审查回复模板，使整个变更提交流程保持一致。

专业提示

  • 将摘要行保持在 ~50 字符以内并使用祈使语气（"add"，而非"added"）——大多数 git tooling 和审查者都期待这一惯例。
  • 在 fix 提交上使用"Closes #[issue]"页脚，使变更的 merge 自动关闭追踪器中关联的 ticket。
  • 将破坏性变更模板保留给真正的契约更改，并始终包含迁移步骤——没有它的破坏性说明只会制造支持负担。
  • 在调试中途双手离开键盘时用 Push-to-Talk 口述提交正文，然后用 AI Enhance 收紧措辞。

在任何应用程序中使用这些模板

从这些示例中创建可重复使用的代码片段，并通过快速访问、触发快捷方式或 AI 增强功能来运行它们。

开始免费试用

相关页面和Snippet

探索适合您的工作流程的相关指南、模板和比较。