writing-commit-messages

To write a commit message that explains why a change was made, use an inverted-pyramid structure with a ~50 character headline, a why-focused lede explaining the behavioral change, and optional technical details to preserve durable intent for future maintainers.

The best way to format pull request descriptions for a squash and merge workflow is to draft them as durable trunk commit messages, ensuring the PR description preserves the rationale and behavioral change details directly in the repository history.

Structure a git commit message for future maintainers using an inverted-pyramid format: start with a ~50 character headline, follow with a why-focused lede, add optional technical details, hard-wrap text to ~80 characters, and maintain consistent tense selection.

Commit messages fail to explain the intent of trunk changes when they lack a clear rationale, use mixed tenses, or omit a why-focused lede, creating noisy repository history that future maintainers cannot easily understand.

Yes, you can use the inverted-pyramid commit message structure for direct trunk commits, applying the same ~50 character headline, why-focused lede, and consistent tense selection to ensure high-quality repository history.

When drafting technical commit messages, apply a ~50 character limit to the headline and hard-wrap the body text to ~80 characters to ensure readability and consistency across the repository history.