Повідомлення коміту читають через місяці: у git log, git blame, при пошуку помилки. «fix», «wip», «правки» нічого не пояснюють.
Структура доброго повідомлення:
Limit login attempts per email and IP ← заголовок до ~50-72 символів
Brute force attempts were spread across IPs, ← порожній рядок, потім тіло
so the per-IP limiter alone did not stop them.
Key the limiter by email and IP together.
Fixes #142 ← посилання на задачу
Правила:
- заголовок - коротко, у наказовому способі («Add», «Fix», а не «Added»), без крапки в кінці;
- тіло пояснює чому і що саме, а не «як» - як видно з diff;
- один коміт - одна логічна зміна: якщо в повідомлення проситься «і ще», комітів має бути два.
Conventional Commits - угода про формат заголовка:
<тип>(<область>): <опис>
feat(auth): add two-factor authentication
fix(billing): round VAT before summing invoice lines
refactor(orders): extract shipping calculator
docs: describe queue configuration
feat(api)!: remove v1 endpoints
Основні типи: feat (нова можливість), fix (виправлення), docs, refactor, test, chore, perf, ci, build. ! після типу чи рядок BREAKING CHANGE: у футері позначають несумісну зміну.
Що дає формат:
- автоматичний changelog і примітки до релізу (release-please, semantic-release);
- семантичне версіювання:
fix- patch,feat- minor, breaking change - major; - історію легко фільтрувати:
git log --oneline --grep '^feat'.
Перевірка формату - commitlint у хуку commit-msg чи в CI. Головне - щоб угоду дотримувалась уся команда, а не окремі люди.