基于代码差异生成规范化 Git 提交信息,并支持按逻辑分组提交
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "git-commit" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/git-commit/SKILL.md 2. 保存为 ~/.claude/skills/git-commit/SKILL.md 3. 装好后重载技能,告诉我可以用了
请分析当前 git diff,按照 Conventional Commits 规范生成提交信息并直接提交;如果包含不同类型改动,请按逻辑分组提交。
生成一个或多个符合 Conventional Commits 的提交,并按改动类型合理拆分。
根据当前代码差异,给我一个 Conventional Commits 风格的提交信息,包含 type、scope 和简洁说明,先不要执行提交。
输出一条规范的提交信息建议,便于手动确认后使用。
请分析当前改动并创建规范提交,关联 GitHub Issue #128;如果改动涉及修复和文档更新,请拆成两个提交。
生成带工作项引用的规范提交,并将修复与文档改动分别提交。
<type>[optional scope]: <description>
[optional body]
[optional footer]
References: Conventional Commits and How to Write a Git Commit Message.
| Type | Usage |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation-only change |
style | Formatting, semicolons, whitespace (no logic change) |
refactor |
| Refactoring without behavior change |
perf | Performance improvement |
test | Adding or fixing tests |
build | Build system or external dependencies |
ci | CI/CD configuration |
chore | General maintenance (scripts, configs) |
revert | Revert a previous commit |
| SDD Artifact | Likely type |
|---|---|
docs/features/**/spec.md | docs |
docs/architecture/decisions/*.md (ADR) | docs |
tasks.md, work items | docs or chore |
| Implementation code | feat, fix, refactor, perf |
| Tests | test |
Agents, skills, instructions (.github/) | chore or ci |
# ! marker after type/scope
feat!: remove deprecated endpoint
# Or BREAKING CHANGE footer
feat(api): allow extensible configuration
BREAKING CHANGE: behavior of the `extends` key changed
# If there are staged files, use staged diff
git diff --staged --stat
git diff --staged
# If nothing is staged, use working tree
git diff --stat
git diff
# Check overall status
git status --porcelain
Determine from the diff:
auth, api, docs, spec)If the diff contains logically distinct changes, group them into separate commits:
# Group by logical area
git add src/auth/*.ts # commit 1: feat(auth)
git add tests/auth/*.test.ts # commit 2: test(auth)
git add docs/features/login/ # commit 3: docs(login)
Principle: one commit = one coherent logical change.
If all changes are part of the same logical unit, stage everything:
git add -A
Before committing, verify:
# Does .gitignore exist?
test -f .gitignore && echo "OK" || echo "⚠ .gitignore missing"
# No secrets being committed?
git diff --staged --name-only | grep -iE '\.(env|pem|key|credentials|secret)' && echo "⚠ POSSIBLE SECRET" || echo "OK"
Never commit: .env, private keys, tokens, credentials, credentials.json.
Before committing, check if the current branch is the integration branch:
CURRENT_BRANCH=$(git branch --show-current)
Resolve the integration branch in this order:
Integration Branch from .memory/git-config.md (if it exists)git symbolic-ref refs/remotes/origin/HEADmain, master, or developIf the current branch matches the integration branch:
You are about to commit directly to `[branch]`. Direct commits to the integration branch bypass code review and are difficult to revert safely.
[B] Create a feature branch first (recommended)
[C] Continue on [branch] (I understand the risks)
If the user chooses [B]:
| Current state | Recovery action |
|---|---|
| Changes are staged but not committed | Run git switch -c <feature-branch> (preserves working tree and index) |
| Changes are unstaged | Run git switch -c <feature-branch> (preserves working tree) |
After switching, continue the commit flow on the new branch.
If the user chooses [C], proceed with the commit. Log the override in the reasoning log (if active).
Never commit to the integration branch without explicit user confirmation.
…
帮助你创建、切换并检查代码分支,确保实现前遵循正确分支策略。
根据当前会话中的代码改动,快速创建可提交的拉取请求。