История из трёх коммитов: как превратить хаотичные сессии кодинга в понятный прогресс

Введение

Вы садитесь покодить «буквально на час». Через три часа у вас изменено десять файлов, вы попробовали три разных подхода, по пути починили несвязанный баг, а история Git превратилась в кладбище коммитов вида wip, oops и fix stuff.

Код вроде бы работает, но прогресс разглядеть сложно. Разобраться, что вообще произошло, — мучение. Будущему вам (или вашим коллегам) будет совершенно непонятно, почему изменения выглядели именно так.

Есть более удачный шаблон работы: история из трёх коммитов.

Это простая практика, которая превращает размытые цели в маленькие, отслеживаемые единицы прогресса — всего с тремя осознанными коммитами на одну сфокусированную сессию. Она помогает:

Избежать растянутых, блуждающих сессий программирования
Сохранить историю Git читаемой и удобной для ревью
Превратить каждый блок работы в осмысленную, задокументированную историю

Разберём, как это работает.

Что такое история из трёх коммитов?

История из трёх коммитов — это небольшой, самодостаточный кусочек прогресса, который вы можете завершить за одну сфокусированную сессию (обычно 30–120 минут).

У неё есть три характеристики:

Малый scope — одно чётко определённое улучшение (например: «добавить поиск в список продуктов», «починить баг в пагинации», «вынести отправку писем в отдельный сервис»).
Три намеренных коммита — вы структурируете работу в три шага, каждый из которых фиксируется отдельным коммитом.
Читаемая история — три коммита вместе рассказывают, что вы сделали и почему.

Вместо того чтобы заходить на задачу как на «реализовать поиск», вы подходите к ней так:

План и скелет: настроить структуру, тесты и заглушки.
Реализация: заставить всё реально работать.
Чистка и рефакторинг: отполировать, упростить и задокументировать.

Каждый из этих шагов становится отдельным коммитом, формируя компактную и понятную историю в вашем Git.

Три осознанных коммита

История из трёх коммитов следует простому шаблону. Вы можете менять формулировки, но общий поток остаётся тем же.

1. Коммит «План / Скелет» (Plan / Scaffold)

Цель: подготовить почву, не реализуя фичу полностью.

Типичные изменения:

Добавить или обновить тесты, которые описывают желаемое поведение
Создать новые файлы, классы или функции как заготовки
Добавить TODO-комментарии или заглушки там, где будет логика
Настроить базовый роутинг или конфигурацию

Пример сообщения коммита:

feat: scaffold product search endpoint

- add /products/search route
- define ProductSearchRequest and response DTO
- add failing integration test for search by name

Почему это важно:

Заставляет вас прояснить, что именно вы собираетесь строить
Даёт чёткую цель (тесты, типы или контракты)
Отделяет дизайн и подготовку от непосредственной реализации

2. Коммит «Реализация» (Implementation)

Цель: заставить это работать. Здесь появляется основная логика.

Типичные изменения:

Реализовать ранее заготовленные методы
Добиться прохождения тестов
Добавить базовую обработку ошибок и happy path

Пример сообщения коммита:

feat: implement product search by name

- query products by name (case-insensitive)
- support partial matches with LIKE
- ensure existing filters still apply

Почему это важно:

Содержит «мясо» изменений в одном месте
Легче ревьюить и отлаживать, потому что намерение прозрачно
Если что-то ломается, это первый коммит, который вы проверяете

3. Коммит «Чистка / Рефакторинг» (Cleanup / Refactor)

Цель: отполировать и стабилизировать только что сделанное.

Типичные изменения:

Рефакторинг для читаемости и поддерживаемости
Удаление дублирования или мёртвого кода
Улучшение именования и структуры
Обновление документации или комментариев

Пример сообщения коммита:

refactor: simplify product search query

- extract query builder to ProductSearchSpecification
- rename params for clarity
- add comments for search behavior

Почему это важно:

Отделяет рефакторинг от изменения поведения
Делает диффы меньше и более осмысленными
Мотивирует не пропускать чистку, потому что у неё есть отдельный «слот»

Вы заканчиваете сессию с историей из трёх актов: скелет → реализация → доводка.

Как писать понятные, ориентированные на действие сообщения коммитов

Истории из трёх коммитов лучше всего работают, когда каждое сообщение коммита короткое, конкретное и ориентировано на действие.

Используйте простую структуру:

Строка-резюме (до ~72 символов)
Необязательное тело для деталей — каждую мысль отдельной строкой или пунктом, объясняющим что и почему

Примеры:

feat: add optimistic locking to order updates

- prevent double-submit from overwriting changes
- surface concurrency error to the UI

fix: handle empty query string in product search

- return 400 instead of 500 on invalid query
- add regression test for empty search

Рекомендации:

Начинайте с глагола: add, fix, remove, refactor, document, rename.
Будьте конкретны: implement product search pagination, а не misc changes.
Используйте тело, чтобы объяснить почему, если решение неочевидно.

В итоге история Git читается как последовательность чётких, небольших действий.

Использование единообразных префиксов для обозначения намерения

Последовательные префиксы позволяют быстро считывать паттерны при просмотре истории. Популярные варианты:

feat: – новая фича или поведение
fix: – исправление бага
refactor: – изменения кода без изменения поведения
docs: – только документация
test: – изменения, связанные с тестами
chore: – инструменты, конфигурация, обслуживание

В истории из трёх коммитов это может выглядеть так:

feat: scaffold product search
feat: implement product search by name
refactor: simplify product search query

Или для фикса бага:

test: add regression test for pagination bug
fix: correct page offset calculation
refactor: extract pagination logic into helper

Эти префиксы помогают:

Быстро фильтровать коммиты по типам
Давать ревьюерам понимание цели каждого изменения
Давать инструментам автоматизации данные для осмысленных changelog’ов

Отношение к истории Git как к документации

Когда вы используете истории из трёх коммитов, ваша история Git перестаёт быть свалкой и превращается в полезную документацию.

Преимущества:

Проще код-ревью

Ревьюер может:

Пройтись по истории коммит за коммитом
Увидеть отдельно этапы дизайна, реализации и чистки
Комментировать меньшие и более сфокусированные диффы

Быстрее отладка

Когда появляется баг, вы можете:

Использовать git blame и увидеть понятное сообщение коммита
Посмотреть историю из трёх коммитов вокруг этой области
Понять, почему было сделано изменение, а не только что поменялось

Легче делиться знаниями

Новые участники команды могут читать историю, чтобы понять, как развивалась система:

«Ага, вот здесь мы добавили optimistic locking».
«Вот как мы делаем рефакторинг без изменения поведения».

Каждая история из трёх коммитов — это маленькая глава в документации вашего проекта.

Превращение истории коммитов в топливо для автоматизации

Хорошо структурированная история коммитов полезна не только людям — это золото для автоматизации.

С единообразными префиксами и понятными сообщениями вы можете настроить инструменты вроде GitHub Actions, GitLab CI или другие пайплайны так, чтобы они:

Генерировали changelog’и из коммитов feat: и fix:
Собирали API-документацию, когда появляются docs: или определённые feat:-коммиты
Автоматически черновили release notes по истории коммитов

Например, пайплайн релиза может:

Просканировать коммиты с момента последнего тега
Сгруппировать их по типам (feat, fix, refactor)
Сформировать секцию changelog’а в markdown для следующего релиза

В какой-то момент ваши дисциплинированные истории из трёх коммитов начинают напрямую подпитывать коммуникации в проекте и процесс релизов.

Как сделать истории из трёх коммитов привычкой

Привычки лучше всего приживаются, когда они простые и повторяемые. Вот как встроить эту практику.

1. Начинайте с маленького scope’а

Спросите себя перед началом работы:

Какую единицу прогресса я могу завершить за одну сфокусированную сессию?

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

2. Назовите свои три коммита заранее

Перед стартом набросайте, например:

feat: scaffold user password reset
feat: implement password reset email flow
refactor: tidy password reset handlers

Это даёт вам мини-дорожную карту и помогает удерживать scope от разрастания.

3. Не смешивайте этапы

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

Поставьте TODO-комментарий
Или запишите в заметки по сессии
Вернитесь к ним в третьем, отдельном коммите на чистку

Так каждый коммит остаётся сфокусированным и удобным для ревью.

4. Практикуйте, а не полицействуйте

Это техника, а не религия. Иногда вам понадобится:

Четвёртый коммит, чтобы поправить тест
Один маленький коммит для какой-нибудь мелочи

Используйте историю из трёх коммитов как направляющий шаблон, а не жёсткое правило. Цель — ясность и прогресс, а не идеальность.

Заключение

Хаотичные сессии программирования возникают, когда цели размыты и изменения сливаются в кашу. История из трёх коммитов даёт вам простую структуру:

Спланировать и накидать скелет изменений
Реализовать поведение
Почистить и отрефакторить результат

Вместе с понятными, ориентированными на действие сообщениями и единообразными префиксами каждая сессия превращается в небольшую, хорошо рассказанную историю в вашей истории Git.

Со временем вы заметите:

Меньше хаоса в ветках
Быстрее и яснее код-ревью
Проще отладку и онбординг новых людей
Историю Git, которая одновременно служит живой документацией

Попробуйте в следующей сессии: выберите маленькую цель, набросайте свои три коммита и посмотрите, как это изменит ваш способ работы. История за историей вы превратите разрозненный, неявный прогресс в понятный, видимый рывок вперёд.