Как писать хорошие сообщения коммитов в 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-изменения. Просмотрите их перед коммитом, чтобы случайно не включить отладочный код или временные файлы.