Construct Commit
Guide to Better Commit Messages
Writing clear, consistent commit logs is a foundational skill for software development. By using this generator, you adopt the structure of Conventional Commits. This format creates a predictable history that scripts, build tools, and human reviewers can process easily.
Why Format Matters
When working in a team or returning to your own code months later, you will likely rely on git log or git blame to understand why a specific line was introduced. A commit message that says "fixed the thing" offers no context. Standardized messages categorize changes (such as features, bug fixes, or chores) and explicitly document breaking updates.
Anatomy of the Message
The standard structure includes three primary sections: header, body, and footer.
- Header (Type + Scope + Description): The first line. It must be concise. Use the imperative, present tense ("add feature" not "added feature" or "adds feature"). Avoid capitalizing the first letter of the description. No period at the end.
- Body: Separated by a blank line from the header. Use this space to explain motivation. Why is this change necessary? How does it differ from the previous behavior?
- Footer: Used primarily for linking to issue tracker IDs (e.g., Fixes #142) and documenting breaking changes. If the code introduces an API break, state it clearly here with BREAKING CHANGE: description.
Common Commit Types
Adhering to strict prefixes helps keep version control scanning fast. feat: Introduces a new feature to the codebase. fix: Patches a bug. docs: Updates documentation files like READMEs or inline docstrings. style: Changes formatting, white-space, missing semi-colons, etc (no production code change). refactor: Rewrites code without changing its external behavior or adding features. test: Adds missing tests or corrects existing ones. chore: Modifies build processes or auxiliary tools/libraries like package managers.
Handling Breaking Changes
If your update forces other developers to change their code to integrate it, that is a breaking change. In this tool, checking "Include Breaking Change indicator" appends an exclamation mark before the colon (e.g., feat(api)!: drop v1 endpoints). It also prepares the footer to accept detailed migration notes. Communication is critical when shipping breaking changes.
Team Presets and History
This workspace operates fully in your browser. When you click "Copy Message", the application saves a local record of your session in your browser cache. You can review your recent work in the Local History panel. Saving a team preset allows you to remember specific scopes or footer formats required by your organization.