Как написать сообщение коммита — чтобы его понял и ты через полгода, и ИИ

Открой историю любого учебного проекта — увидишь примерно такое: fix, fix2, изменения, наконец работает. Написано за секунду, и кажется, что неважно: код же главное.

А теперь неожиданный поворот: сообщение коммита ты пишешь не себе-сегодняшнему. У него два настоящих читателя — ты через полгода, который забыл всё и ищет, где сломалось, — и ИИ-агент, который читает историю проекта, чтобы понять, что здесь происходило. Обоим fix2 не говорит ничего. Давай напишем так, чтобы говорило.

Шаг за шагом

1. Сначала посмотри, что коммитишь. Перед сообщением набери git status и git diff — освежи, что именно изменилось. Хорошее сообщение описывает реальные изменения, а не «что я вроде бы делал». Если изменений набралось на три разные темы — раздели на три коммита: один коммит = одно осмысленное изменение.

2. Напиши заголовок: что меняет коммит, до 50 символов. Формула — продолжи фразу «этот коммит … »: «добавляет валидацию email», «чинит краш при пустой корзине». В английской традиции заголовок пишут в повелительной форме: add email validation, fix cart crash — коротко и единообразно:

   git commit -m "fix crash when cart is empty"
   

3. Добавь тип-префикс — одно слово с двоеточием в начале: feat: (новая функциональность), fix: (починка), docs:, refactor:, chore: (рутина). Это конвенция conventional commits — её понимают люди, инструменты и модели:

   git commit -m "fix: crash when cart is empty"
   

4. Если причина неочевидна — допиши тело: почему. Вторая -m добавляет абзац-пояснение. Что изменилось, видно из кода; из сообщения должно быть видно зачем:

   git commit -m "fix: crash when cart is empty" -m "The total() call assumed at least one item. Guard added because guest users can open the cart before adding anything."
   

5. Проверь себя чужими глазами: git log --oneline -5 печатает пять последних заголовков. Читается как связная история проекта? Отлично. Видишь fix2 — теперь ты знаешь, что с этим делать.

Что получится

История, в которой можно ориентироваться без археологии:

feat: add email validation on signup
fix: crash when cart is empty
docs: add setup steps to README
refactor: extract price logic into helper

По такой истории мгновенно видно, где искать сломавшееся («что мы трогали в последнее время?»), её приятно показать в портфолио — и, главное на практике, откат делается осмысленно: когда понадобится отменить коммит, ты будешь выбирать между понятными строками, а не гадать, что скрывается за fix2.

Хорошо и плохо — на примерах

• ❌ изменения → ✅ feat: add dark theme toggle — «изменения» есть в каждом коммите, это ноль информации.
• ❌ починил баг → ✅ fix: avatar upload fails for files over 5 MB — какой баг? Их будут десятки.
• ❌ feat: added new feature and fixed bugs and updated readme → ✅ три отдельных коммита — «и… и… и» в заголовке = сигнал разделить.
• ❌ WIP, asdf, final-final2 → ✅ любой честный заголовок: даже простое fix: typo in login form лучше.

Причём здесь ИИ

Два практических момента. Первый: ИИ-агенты вроде Claude Code читают git log, когда разбираются в проекте, — внятная история буквально делает агента умнее в твоём проекте, это часть контекста. Второй: сообщение коммита можно ИИ и поручить — попроси «напиши сообщение коммита по этому diff» и дай вывод git diff. Модель хорошо пишет «что», но «почему» знаешь только ты — причину нетривиального решения дописывай сама или сам. Остальные ежедневные команды — в подборке команд Git для новичка.

На каком языке писать — на русском или английском?

Выбери один язык на проект и держись его. Опенсорс и рабочие проекты — почти всегда английский. Личный проект — как удобно, но помни: английские сообщения понимает больше инструментов, и портфолио с ними выглядит привычнее.

Каждому коммиту нужно длинное тело?

Нет. Мелким очевидным изменениям хватает заголовка. Тело нужно там, где будущий ты спросит «зачем это сделано?» — неочевидная причина, обход чужого бага, важное решение.

Что делать, если уже отправил коммит с плохим сообщением?

Последний неотправленный коммит можно переписать: git commit --amend -m "новое сообщение". Если коммит уже ушёл в общую ветку на сервер — не переписывай историю, просто пиши лучше со следующего.