Як писати хороші повідомлення комітів у Git?

Гарне повідомлення коміту допомагає команді розуміти історію і спрощує налагодження. Ось правила та практики.

Структура повідомлення: перший рядок — коротка зведення, не більше 50 символів, у наказовому способі: "Додати валідацію форми реєстрації", а не "Додав валідацію". Після порожнього рядка — детальний опис: що змінилося і чому, не як (код сам показує як). Опис — до 72 символів на рядок.

Conventional Commits — популярний стандарт форматування. Формат: type(scope): description. Типи: feat (нова функція), fix (виправлення багу), docs (документація), style (форматування), refactor (рефакторинг), test (тести), chore (обслуговування), perf (продуктивність), ci (CI-конфігурація). Приклад: feat(auth): додати OAuth2 авторизацію через Google. Це дозволяє автоматично генерувати changelog і керувати версіями.

Практичні правила: один коміт — одна логічна зміна. Не змішуйте рефакторинг і нову функцію в одному коміті. Якщо зміна зачіпає кілька файлів, але всі вони частина одного завдання — це один коміт. Комітьте часто — маленькі коміти легше відкочувати і перевіряти.

Чого уникати: повідомлень типу "fix", "update", "wip", "різні правки". Повідомлення "виправити баг" не каже нічого — який баг, де, як. Краще: "fix(cart): виправити розрахунок суми при порожньому промокоді". Не пишіть повідомлення в минулому часі — "додав" замість "додати".

Багаторядкові повідомлення: використовуйте git commit без -m — відкриється редактор. Або кілька прапорців -m: git commit -m "короткий опис" -m "детальний опис у другому абзаці".

Перевірка перед комітом: git diff --cached показує staged-зміни. Перегляньте їх перед комітом, щоб випадково не включити налагоджувальний код або тимчасові файли.