Как писать понятные коммиты
Разработчики, когда отправляют код в центральное его хранилище, обычно пишут сопровождающее сообщение.
Плохой коммит, а точнее, сообщение о коммите - это как в старом анекдоте:
- Петрович, Приборы?!
- 42!
- Что «42»?
- А что «приборы»?
Хороший коммит — это мини-история: что было, что сделал и зачем.
Далее приведу несколько правил, которые делают твой git-лог читаемым, а тебя - душой команды.
1️⃣ Пиши коротко, но по сути
❌ Не подойдет: fix update change something
✅ Подойдет: fix: исправил падение при пустом payload feat: добавил фильтр по дате в отчётах
Короче, если заголовок не объясняет, что произошло — коммит бесполезен.
2️⃣ Один коммит — одна мысль
Не смешивай всё в одну кучу. Если коммит называется «исправил верстку», а внутри 17 файлов по логике, то суть немного так потеряна.
3️⃣ Добавляй описание, если нужно
Если коммит не очевидный — дай немного контекста. Но без романов на три страницы.
Пример:
fix: корректная обработка null в billing-service
Причина: при расчёте скидки приходил null, который ломал пайплайн. Решение: добавил fallback + логирование.
4️⃣ Не бойся признаться в правде
Иногда лучший коммит — честный коммит: refactor: удалил свой вчерашний костыль и переписал нормально fix: устранил то, что сам сломал вчера
5️⃣ Вместо итогов
Понятные коммиты - это уважение к команде и к себе любимому в будущем. Так как через полгода именно ты будешь искать, что и почему сделали.
