git-commit

name	git-commit
description	Execute Git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit, commit changes, create a Git commit, or mentions /commit. Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
license	MIT
metadata	{"source":"https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md"}

Git Commit with Conventional Commits

Overview

Create standardized, semantic Git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.

Conventional Commit Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

Type	Purpose
feat	New feature
fix	Bugfix
docs	Documentation only
style	Formatting/style (no logic)
refactor	Code refactor (no feature/fix)
perf	Performance improvement
test	Add/update tests
build	Build system/dependencies
ci	CI/config changes
chore	Maintenance/misc
revert	Revert commit

Breaking Changes

# Exclamation mark after type/scope
feat!: remove deprecated endpoint

# BREAKING CHANGE footer
feat: allow config to extend other configs

BREAKING CHANGE: `extends` key behavior changed

Workflow

1. Analyze Diff

# If files are staged, use staged diff
git diff --staged

# If nothing staged, use working tree diff
git diff

# Also check status
git status --porcelain

2. Stage Files (if needed)

If nothing is staged or you want to group changes differently:

# Stage specific files
git add path/to/file1 path/to/file2

# Stage by pattern
git add *.test.*
git add src/components/*

# Interactive staging
git add -p

Never commit secrets (.env, credentials.json, private keys).

3. Generate Commit Message

Analyze the diff to determine:

• Type: What kind of change is this?
• Scope: What area/module is affected?
• Description: One-line summary of what changed (present tense, imperative mood, <72 chars)

4. Execute Commit

# Single line
git commit -m "<type>[scope]: <description>"

# Multi-line with body/footer
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>

<optional body>

<optional footer>
EOF
)"

Best Practices

• One logical change per commit
• Present tense: "add" not "added"
• Imperative mood: "fix bug" not "fixes bug"
• Reference issues: Closes #123, Refs #456
• Strict 50/72 Character Rule:
  • The commit subject (first line) must not exceed 50 characters.
  • All subsequent body/footer lines must be wrapped to not exceed 72 characters.
• Use Bulleted Lists for Clarity: If the commit describes multiple distinct but related changes, use a bulleted list in the body. Ensure each bullet point is wrapped to 72 characters.

Git Safety Protocol

• NEVER update Git config
• NEVER run destructive commands (--force, hard reset) without explicit request
• NEVER skip hooks (--no-verify) unless user asks
• NEVER force push to main/master
• If commit fails due to hooks, fix and create NEW commit (don't amend)

Troubleshooting & Container Permissions

• Permission Denied on Git Control Files: In containerized or volume-mounted sandboxes (e.g. Docker environments running as root), containers might alter ownership of Git control files (such as .git/config or .git/index) to root.
• Resolution: If Git commits fail with Permission denied errors, run ls -la .git/ to check file ownership. Report permissions/ownership issues directly to the user so they can restore proper ownership (e.g., using chown).