360 Secure SkillHub
360 安全技能中心

writing-git-commits

提供 Conventional Commits 类型、作用域、主题行、正文与脚注规则，并给出检查暂存变更和起草提交信息的工作流，帮助避免含糊、过宽或混入无关改动。

ink5725
ink5725
热度 27.21
最近更新 2026-09-08 16:02:14
分类：开发依赖：代码执行应用场景：代码审查 / 工作流 / 模板

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add ink5725/my-first-skill
Metadata
name
writing-git-commits
description
Use when creating git commit messages, preparing to commit changes, or when commit history is messy, inconsistent, or hard to review. Covers conventional commit format, scope selection, and message hygiene.

Writing Git Commits

Overview

Write clean, conventional commit messages that make history readable and reviewable.

Core principle: A commit message should let a reviewer understand why a change was made without reading the diff.

When to Use

  • About to run git commit or git commit --amend
  • Writing a commit message for staged changes
  • Squashing or rewriting commit history
  • User asks to "commit this" or "make a commit"

Do NOT use for:

  • Deciding what to stage (that's a code review concern)
  • Merge commits auto-generated by git tooling

Commit Format

Follow Conventional Commits:

<type>(<scope>): <subject>

<body>
<footer>

Quick Reference: Types

Type Use for
feat New feature
fix Bug fix
docs Documentation only
style Formatting, whitespace, no logic change
refactor Code change that neither fixes nor adds
perf Performance improvement
test Adding or correcting tests
chore Maintenance, deps, build, CI
revert Reverting a previous commit

Rules

  1. Subject line

    • Imperative mood: "add", not "added" or "adds"
    • No period at the end
    • Max 72 characters
    • Lowercase after the colon

  2. Body (optional)

    • Wrap at 72 characters
    • Explain why, not what (the diff shows what)
    • Blank line between subject and body

  3. Footer (optional)

    • Breaking changes: BREAKING CHANGE: <description>
    • Issue refs: Closes #123, Fixes #456

Example

Good:

fix(auth): prevent login when session cookie is expired

Sessions were validated by presence, not expiry time, allowing
stale cookies to authenticate users after logout.

Adds an explicit expiry check in validate_session() and a
regression test covering the expired-cookie path.

Closes #284

Bad:

fixed stuff

Why bad: no type, no scope, no context; "stuff" is unsearchable.

Workflow

  1. Run git status and git diff --staged to see what is actually committed
  2. Identify the dominant change type (feat/fix/docs/...)
  3. Choose the narrowest meaningful scope (module, file, or component name)
  4. Draft subject, verify under 72 chars and imperative mood
  5. Add body only if the "why" is not obvious from the diff
  6. Reference issues in the footer when they exist

Common Mistakes

Mistake Fix
Vague subjects ("update") Name the concrete change and module
Describing the diff in body Explain motivation and trade-offs instead
Multiple unrelated changes Split into separate commits
Past tense ("added") Use imperative ("add")
Overly wide scope ("app") Use the affected module or file

Red Flags - STOP Before Committing

  • Subject does not start with a known type
  • Subject over 72 characters
  • Mixing unrelated changes in one commit
  • Message could describe any commit ("improve code")

Any of these: rewrite the message before committing.