Writing clear, structured commit messages makes collaboration smoother, code reviews easier, and project history understandable. Here's a simple guide I follow:ā£
ā£
Commit Message Structureā£
ā£
<type>(<scope>): <short description>ā£
ā£
ā£
- type ā the kind of changeā£
- scope ā optional, the affected moduleā£
- description ā concise summary (imperative mood)⣠⣠### Common Types⣠ā£
-
feat:ā new features⣠-
fix:ā bug fixes⣠-
chore:ā maintenance, build updates, configs⣠-
docs:ā documentation⣠-
refactor:ā code improvements without changing behavior⣠-
style:ā formatting, linting, whitespace⣠-
test:ā adding/updating tests⣠⣠Example:⣠ā£
feat(auth): add login with Googleā£
fix(api): handle null pointer on user fetchā£
chore: update dependenciesā£
ā£
ā£
Best Practicesā£
ā£
-
Imperative tone ā describe what the commit does:ā£
ā
fix(ui): remove extra padding on button⣠āfixed padding issue⣠⣠- Keep subject short ā ⤠50 characters⣠ā£
- Use body for details ā explain why, not just what:⣠ā£
feat(auth): add password resetā£
ā£
- Added endpoint /auth/reset-passwordā£
- Updated email templatesā£
- Closes #123ā£
ā£
ā£
ā
Clean commits = better teamwork & smoother code history! š ļøš”ā£
Top comments (2)
It is very useful, thanks!
You are welcome :)