Advanced Commit Platform

A git commit management skill for crafting well-structured commits, enforcing conventional commit standards, managing commit history, and automating commit workflows.

When to Use

Choose Advanced Commit Platform when:

• Enforcing conventional commit message formats across a team
• Automating commit message generation from code changes
• Managing complex commit histories with interactive rebasing workflows
• Setting up git hooks for commit validation and automated checks

Consider alternatives when:

• Simply making a quick commit — use standard git commit directly
• Managing releases and changelogs — use semantic-release or standard-version
• Reviewing commit history — use git log with formatting options

Quick Start

Copy
# Conventional commit format
git commit -m "feat(auth): add OAuth2 login with Google provider

- Implement GoogleOAuthStrategy class
- Add /auth/google callback endpoint
- Store refresh tokens in encrypted user session

Closes #142"

# Set up commitlint with husky
npm install -D @commitlint/{cli,config-conventional} husky
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
npx husky init
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Copy
import subprocess
import re

class CommitManager:
    TYPES = {
        "feat": "A new feature",
        "fix": "A bug fix",
        "docs": "Documentation only changes",
        "style": "Formatting, missing semi-colons, etc",
        "refactor": "Code change that neither fixes a bug nor adds a feature",
        "perf": "A code change that improves performance",
        "test": "Adding missing tests or correcting existing tests",
        "build": "Changes to build system or external dependencies",
        "ci": "Changes to CI configuration files and scripts",
        "chore": "Other changes that don't modify src or test files"
    }

    def analyze_diff(self):
        """Analyze staged changes to suggest commit type"""
        result = subprocess.run(
            ["git", "diff", "--cached", "--stat"],
            capture_output=True, text=True
        )
        files = result.stdout.strip().split("\n")[:-1]

        test_files = [f for f in files if "test" in f.lower() or "spec" in f.lower()]
        doc_files = [f for f in files if any(ext in f for ext in [".md", ".rst", ".txt"])]
        ci_files = [f for f in files if any(p in f for p in [".github", "Jenkinsfile", ".gitlab"])]

        if len(test_files) == len(files):
            return "test"
        elif len(doc_files) == len(files):
            return "docs"
        elif len(ci_files) == len(files):
            return "ci"
        return "feat"

    def validate_message(self, message):
        """Validate conventional commit format"""
        pattern = r'^(feat|fix|docs|style|refactor|perf|test|build|ci|chore)(\(.+\))?(!)?: .{1,72}'
        if not re.match(pattern, message):
            return False, "Message must follow conventional commit format"

        lines = message.split("\n")
        if len(lines[0]) > 72:
            return False, "Subject line exceeds 72 characters"
        if len(lines) > 1 and lines[1] != "":
            return False, "Second line must be blank (separates subject from body)"
        return True, "Valid"

    def create_commit(self, commit_type, scope, description, body=None, breaking=False):
        """Create a properly formatted conventional commit"""
        prefix = f"{commit_type}({scope})" if scope else commit_type
        if breaking:
            prefix += "!"
        message = f"{prefix}: {description}"
        if body:
            message += f"\n\n{body}"

        subprocess.run(["git", "commit", "-m", message])

Core Concepts

Conventional Commit Types

Type	Purpose	Changelog Section	SemVer Bump
feat	New feature for users	Features	Minor
fix	Bug fix for users	Bug Fixes	Patch
docs	Documentation changes	—	—
style	Code formatting only	—	—
refactor	Code restructuring	—	—
perf	Performance improvements	Performance	Patch
test	Test additions/changes	—	—
build	Build system changes	—	—
ci	CI/CD pipeline changes	—	—
chore	Maintenance tasks	—	—
feat! / fix!	Breaking change	BREAKING CHANGES	Major

Git Hooks for Commit Quality

Copy
#!/bin/bash
# .husky/pre-commit - Run checks before allowing commit

# Type check
npx tsc --noEmit || {
    echo "TypeScript errors found. Fix before committing."
    exit 1
}

# Lint staged files only
npx lint-staged || {
    echo "Linting failed. Fix issues before committing."
    exit 1
}

# Run affected tests
npx jest --bail --findRelatedTests $(git diff --cached --name-only --diff-filter=ACMR | grep -E '\.(ts|tsx)$') || {
    echo "Tests failed. Fix before committing."
    exit 1
}

Configuration

Option	Description	Default
commit_format	Message format standard	"conventional"
max_subject_length	Maximum subject line characters	72
require_scope	Require scope in commit messages	false
allowed_scopes	Valid scope values	[] (any)
require_body	Require commit body	false
require_issue_ref	Require issue reference in footer	false
sign_commits	Enable GPG commit signing	false
pre_commit_hooks	Hooks to run before committing	["lint","typecheck"]

Best Practices

1. Make atomic commits that represent a single logical change — each commit should be independently revertable without breaking unrelated functionality; avoid mixing feature code with formatting changes in the same commit
2. Write commit subjects in imperative mood starting with a verb ("Add feature" not "Added feature") to match git's own generated messages and maintain a consistent readable history
3. Use commit body for the why, not the what — the diff already shows what changed; the body should explain the reasoning, trade-offs considered, and any non-obvious implications
4. Reference issue numbers in commit footers to maintain traceability between code changes and the requirements or bugs that motivated them
5. Keep commits buildable so that bisecting through history to find a bug-introducing commit works correctly — every commit in the chain should compile and pass basic tests

Common Issues

Commit message validation rejects valid messages: Custom commitlint rules may be too strict or have unexpected parsing behavior with special characters in scopes. Test rules against your team's actual commit patterns, adjust the regex configuration, and provide clear error messages that show the expected format.

Large commits that should have been split: Developers often accumulate changes and commit everything at once. Use git add -p for interactive staging to select specific hunks, create focused commits from a large set of changes, and encourage work-in-progress commits on feature branches.

Merge conflicts in commit hooks configuration: Husky and commitlint configuration files frequently conflict when multiple developers modify them simultaneously. Keep hook configurations simple, put complex validation logic in shared scripts rather than inline in hook files, and resolve conflicts by keeping the most restrictive version.