Git Commit

Git commits require clear messages following conventions for maintainable history and effective collaboration. This skill guides commit message writing covering format conventions, content guidelines, atomic commit principles, and best practices ensuring repository history remains valuable documentation of project evolution.

What Is This?

Overview

Git Commit provides comprehensive guidance for writing quality commit messages. It explains conventional commit format with type prefixes, demonstrates clear subject line writing, shows proper commit body structure, covers breaking change documentation, illustrates commit scope specification, and enforces atomic commit principles ensuring each commit represents single logical change.

The skill emphasizes commit messages as documentation communicating change intent to future developers. Well-written commits enable efficient code archaeology and understanding of project evolution, reducing the time developers spend deciphering historical changes.

Who Should Use This

Software developers making commits. Team leads establishing standards. Code reviewers enforcing quality. Open source contributors. Git beginners learning practices. Teams adopting conventions.

Why Use It?

Problems It Solves

Vague commit messages lack context making history useless. Clear messages document why changes were made, providing essential reasoning that code alone cannot convey.

Large commits mixing concerns complicate reverting and understanding. Atomic commits isolate changes enabling precise operations.

Inconsistent message format hampers automated tooling. Conventional commits enable changelog generation and version management.

Missing context requires code inspection. Comprehensive messages explain reasoning and context immediately.

Core Highlights

Conventional commit format. Clear subject line writing. Descriptive body content. Breaking change documentation. Atomic commit principles. Type prefix usage. Scope specification. Footer conventions.

How to Use It?

Basic Usage

Structure commits with type, optional scope, subject, body, and footer. Keep changes atomic and messages descriptive. The type prefix immediately communicates the nature of the change to anyone reviewing history.

feat(auth): add OAuth2 authentication
fix(api): correct pagination offset calculation
docs: update installation instructions

Specific Scenarios

For features, describe what was added.

feat(payment): integrate Stripe payment processing

Add Stripe SDK integration for credit card payments.
Includes payment form, webhook handling, and receipt generation.

For fixes, explain problem and solution.

fix(search): resolve timeout on large datasets

Previous implementation loaded all results before displaying.
Changed to cursor-based pagination preventing timeouts.

Fixes #123

For breaking changes, document migration.

feat(api)!: change response format to camelCase

BREAKING CHANGE: All API responses now use camelCase instead
of snake_case. Update clients to handle new format.

Real World Examples

A team adopts conventional commits for automated versioning. Commit messages now include type prefixes indicating change severity, subject lines summarizing changes concisely, bodies explaining context and reasoning, footers referencing related issues, and breaking change markers triggering major version bumps. Release notes generate automatically from commit history.

A developer debugs production issue requiring understanding when behavior changed. Commit history with clear messages enables quickly finding relevant commits, understanding why changes were made, identifying when regression was introduced, and determining appropriate fix. Well-written commits serve as valuable debugging documentation.

An open source project receives contributions with poor commit messages like "fix bug" and "update code". Maintainer documents commit guidelines covering conventional commit format, atomic change requirements, subject line clarity, and body context expectations. Contribution quality improves with contributors writing informative messages helping maintainers understand changes quickly and reducing review cycles.

Advanced Tips

Use conventional commit types consistently. Write imperative subject lines using present tense verbs such as "add", "fix", or "remove" rather than past tense. Explain why not what. Keep commits atomic. Reference issues in footers. Sign commits for verification. Use co-authored-by for pairing. Amend recent commits carefully. Squash before merging when appropriate.

When to Use It?

Use Cases

Daily development commits. Feature implementation. Bug fixes. Documentation updates. Refactoring. Code review preparation. Open source contributions. Automated release workflows.

Related Topics

Conventional commits specification. Semantic versioning. Git best practices. Code review processes. Automated changelog generation. Commit message linting. Git hooks.

Important Notes

Requirements

Understanding of Git basics. Team agreement on conventions. Commit message linter optional but recommended for enforcing consistency automatically. Knowledge of conventional commit types. Discipline in following practices.

Usage Recommendations

Follow conventional commit format. Keep commits atomic. Write clear subject lines under 72 characters. Provide context in body. Reference issues appropriately. Sign commits for security. Use present tense imperatively. Review before pushing.

Limitations

Requires team discipline. Conventions vary across projects. Automated tools need configuration. Cannot fix poor development practices. Should balance detail with brevity.