Как писать сообщения коммита

Короткие, ясные сообщения коммита ускоряют совместную работу и упрощают поддержку кода. Следуйте простой структуре: Type, Description, Body и Footer; используйте императивное наклонение и ограничение строки для заголовка. Ниже — правила, шаблоны, чек‑листы и примеры, которые можно брать в работу сразу.

Плюшевая игрушка GitHub Octocat на фоне размытых терминальных строк .jpg)

Коммит‑сообщения — это краткие описания изменений в системе контроля версий (например, Git). При фиксации изменений вы объясняете, что именно изменили и почему. Хорошие сообщения выполняют две ключевые задачи: документируют историю проекта и упрощают коммуникацию между разработчиками.

Краткая структура хорошего сообщения коммита

Хорошее сообщение коммита состоит из четырёх частей:

Type — тип изменения.
Description — краткий заголовок (summary).
Body — подробное описание (опционально).
Footer — метаданные и ссылки на задачи (опционально).

Общий шаблон выглядит так:

: 

[опциональное тело]

[опциональный футер]

Важно: оставьте пустую строку между Description и Body, чтобы Git корректно отделял заголовок от тела.

Type — какой тип изменений вы вносите

Тип показывает категорию изменения. Вы можете использовать любую систему тэгов, которая подходит вашей команде. Часто встречающиеся варианты:

feat: добавление новой функции.
fix: исправление ошибки.
refactor: реорганизация кода без добавления фич или исправления ошибок.
test: изменения, связанные с тестами.
chore: вспомогательные изменения (обновление зависимостей, скрипты и т. п.).
docs: изменения в документации.
style: правки оформления кода, не влияющие на поведение (пробелы, точки с запятой).
perf: улучшения производительности.
build: изменения в сборке или зависимостях билд‑системы.
ci: изменения в настройках CI/CD.
revert: откат к предыдущему коммиту.

Совет: договоритесь с командой о наборе типов и оформите это в CONTRIBUTING.md.

Description — заголовок коммита

Описание должно быть коротким и содержательным:

Сформулируйте заголовок так, чтобы его было достаточно для понимания сути коммита с первого взгляда.
Желательно ограничиться 50 символами или менее.
Пишите в настоящем времени и в императиве: «Добавить», «Исправить», «Удалить». Это общепринятая практика (как «Apply», «Fix»), и она хорошо читается в логах.
Начинайте с заглавной буквы.
Не завершайте заголовок точкой.

Пример:

feat: Добавить переключатель тёмной темы на главной странице

Здесь используется тип feat, потому что добавляется новая функциональность.

Body — подробности (опционально)

Тело даёт контекст: почему было принято решение, какие сценарии затрагиваются, какие компромиссы или побочные эффекты есть. Его стоит использовать, когда одно‑предложение недостаточно.

Правила для тела:

Оборачивайте текст вручную на ~72 символа для удобства чтения в терминале.
Объясняйте мотивы и последствия изменения, указывайте альтернативы, которые вы рассматривали.
Используйте маркеры или отдельные абзацы, если коммит сложный.
Оставьте пустую строку между заголовком и телом.

Пример:

feat: Добавить GitHub как провайдера OAuth

Интегрировать GitHub как провайдера OAuth для упрощённой
аутентификации по аккаунтам GitHub.

- Реализовать поток OAuth через GitHub API
- Настроить эндпоинты и параметры конфигурации
- Добавить опцию входа через GitHub в UI

Footer — дополнительные ссылки и метки (опционально)

В футере можно указывать ссылки на задачи, баг‑репорты или специальные теги, которые ваша система поддерживает (например, закрытие issue):

Resolves: #123
See also: #456, #789

Формат и ключевые слова (Resolves, Closes) зависят от системы трекинга задач вашего проекта.

Как добавлять сообщение коммита в Git

Для коротких сообщений используйте флаг -m:

git commit -m "chore: Change linter to ESlint"

Для длинных сообщений лучше открыть редактор (по умолчанию Git использует $GIT_EDITOR или $EDITOR):

git commit

Можно также подготовить файл с сообщением и передать его через –file:

git commit --file commit_message.txt

Примеры типовых сообщений

feat: Добавить страницу профиля пользователя
fix: Исправить падение при сохранении формы профиля
docs: Обновить README с инструкцией по деплою
test: Добавить юнит‑тесты для сервиса оплаты
chore: Обновить зависимости и изменить конфигурацию линтера

Шаблон коммита и чек‑лист перед коммитом

Используйте простой шаблон, чтобы стандартизировать сообщения:

: <Краткое описание>

[Подробное объяснение, зачем и что изменено]

[Список ключевых изменений]

[Resolves: #номер_задачи]

Чек‑лист для разработчика перед коммитом:

Заголовок короткий и информативный (≤50 символов).
Заголовок в императиве и без точки в конце.
Если нужно — добавлено тело с объяснением причин и последствий.
В теле использована разбивка по пунктам для сложных изменений.
Ссылки на задачи/issue добавлены в футер.
Коммит атомарен (по возможности): одна логическая единица.

Чек‑лист для ревьюера:

Сообщение отражает суть изменений.
Есть контекст и мотивация (если коммит нетривиален).
Нет побочных изменений, не относящихся к задаче.

Модель принятия решения: когда писать длинное сообщение

Используйте длинное тело, когда:

Внесены архитектурные изменения.
Исправление багов с нетривиальной причиной.
В коммите несколько логических шагов или изменений в нескольких подсистемах.

Короткий заголовок достаточен, когда:

Изменение тривиально (правка опечатки, пробелы, форматирование).
Коммит ограничен одной простой задачей.

Примеры — до и после

Плохо:

fix: stuff

Хорошо:

fix: Исправить падение при сохранении комментариев без авторизации

Проблема возникала при попытке сохранить комментарий, если
пользователь не был залогинен — сервер возвращал 500.
Добавлена проверка авторизации и соответствующий код ответа 401.

Resolves: #321

Противоположные примеры — когда правило не работает

Очень мелкие правки, связанные только с форматированием (style/chore): длинные тела не нужны.
Экспериментальные ветки: иногда удобно коммитить часто и описывать ход эксперимента в ветке, но перед слиянием стоит Squash или переработать историю.
Автогенерируемые файлы (build outputs): коммиты могут быть машинными и не требовать детального описания, но лучше исключить их из репозитория.

Альтернативные подходы и инструменты

Conventional Commits — формальный набор правил, полезен при автоматизации релизов.
Commitizen — интерактивный тул для оформления сообщений по шаблону.
Semantic Release — автоматическая генерация релизов и CHANGELOG по сообщениям коммитов.

Если ваша команда использует CI, можно интегрировать проверки сообщений (pre‑commit hook или CI job), чтобы валидировать формат.

Ментальные модели и эвристики

«Один коммит — одна логическая задача». Если изменение затрагивает разные задачи, разбейте на несколько коммитов.
«Заголовок = что, тело = почему». Заголовок говорит, что сделано; тело объясняет, зачем.
«Императив + настоящее время» читабельнее при применении команд (Apply/Remove/Update).

Роли и обязанности

Разработчик: пишет понятные и атомарные сообщения, добавляет ссылки на задачи.
Ревьюер: проверяет соответствие сообщения содержимому и просит улучшений при необходимости.
Мейнтейнер: контролирует, чтобы сообщения в основной ветке были однородны и читабельны; при необходимости переписывает историю перед релизом.

Быстрый набор шаблонов (cheat sheet)

Новая функциональность:

feat: <Короткое описание>

<Подробности и список изменений>

Исправление бага:

fix: <Короткое описание>

<Причина бага и способ исправления>

Resolves: #номер

Рефакторинг:

refactor: <Короткое описание>

<Почему рефакторинг нужен, риск и тесты>

Факты и рекомендуемые числа

Заголовок: ≈50 символов или меньше.
Тело: перенос строк примерно через 72 символа.
Отделяйте заголовок от тела одной пустой строкой.

Decision flowchart (простая схема принятия решения)

flowchart TD
  A[Начало: собираетесь коммитить] --> B{Коммит тривиален?}
  B -- Да --> C[Используйте короткий заголовок]
  B -- Нет --> D{Изменение включает несколько областей?}
  D -- Да --> E[Разбейте на несколько коммитов]
  D -- Нет --> F[Добавьте тело с контекстом]
  C --> G[Добавьте type и description]
  E --> G
  F --> G
  G --> H[Проверьте чек‑лист и закомитьте]

Критерии приёмки

Заголовок чётко отражает изменения.
Тело объясняет мотивацию и побочные эффекты (если есть).
Ссылки на задачи указаны в футере.
Коммит атомарен либо логически завершён.

Короткая глоссарий (1 строка каждое)

Commit: зафиксированное изменение в репозитории.
Header (заголовок): первая строка сообщения — краткий резюме.
Body: развёрнутое объяснение причин и последствий.
Footer: метаданные и ссылки на issue/PR.

Заключение

Хорошие сообщения коммита — небольшая инвестиция времени, возвращающаяся многократно: проще ревью, легче отладка, понятная история релизов. Договоритесь в команде о формате, автоматизируйте проверку и используйте шаблоны, чтобы стандартизировать процесс.

Важно: начните с простых правил и постепенно усложняйте их по мере роста команды и проекта.