Одна задача — один понятный коммит

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

Атомарный коммит: одна задача — один коммит

Коммит атомарен, если он фиксирует ровно одно логически завершённое изменение. Не один файл, не одну строку — а одну задачу. В README.md можно за раз исправить описание проекта и добавить раздел навигации: это два изменения в одном файле, но это две разные задачи, и правильно сохранить их двумя разными коммитами.

Почему это важно? Когда через неделю кто-то (или вы сами) смотрит на историю, каждый коммит должен отвечать на вопрос: «что именно изменилось и зачем?». Если в одном коммите смешаны правка описания и добавление навигации, ответить на этот вопрос нельзя без открытия diff и его разбора. Атомарный коммит делает ответ очевидным из одной строки.

Разделяйте правки, если они дают два независимых результата, которые можно отдельно понять и проверить. Например, уточнение описания и добавление навигации в этом упражнении решают разные задачи. Возможность описать один результат разными словами сама по себе не требует двух коммитов. Количество затронутых строк или файлов роли не играет. Одна строка, исправляющая опечатку в заголовке, — полноценный коммит. Десять строк, добавляющих связанный раздел, — тоже один коммит, если они решают одну задачу.

Сообщение коммита: результат, а не действие

Сообщение коммита — не дневник о том, что вы делали, а описание того, что теперь стало по-другому. Разница на практике:

• Редактировал README — описывает действие; из этой строки непонятно, что именно изменилось.
• Уточнено описание проекта в README — описывает результат; из одной строки ясно, что именно изменилось.

Критерий проверки прост: прочитайте своё сообщение в выводе git log --oneline — не открывая diff. Если из сообщения понятно, что именно стало иначе, формулировка рабочая. Если нет — переформулируйте.

Несколько ориентиров для хорошего сообщения:

• Начинайте с глагола в прошедшем времени или с существительного, описывающего результат: «Добавлен раздел навигации», «Исправлена опечатка в заголовке».
• Не пишите «файл изменён», «обновлено» без уточнения — это шум, а не информация.
• Будьте конкретны настолько, чтобы отличить этот коммит от соседних.

Сообщение передаётся флагу -m в кавычках: git commit -m "Уточнено описание проекта в README". Именно эта строка будет видна в git log --oneline рядом с сокращённым ID коммита.

Последовательность двух независимых коммитов из одного файла

Старт упражнения. Используйте чистый учебный репозиторий git-history после подготовки из секции 2 урока 06: в нём четыре коммита — Init project, Add contacts, Add notes, Update intro; отслеживаются README.md и notes.md. Строк Описание: учебный репозиторий и ## Навигация в README.md ещё нет. Перед началом выполните git status: он должен сообщить nothing to commit, working tree clean; других подготовленных или рабочих правок нет. В этом упражнении notes.md не меняйте.

Если это упражнение уже выполнено или в репозитории есть другие незавершённые правки, подготовьте новый отдельный репозиторий по секции 2 урока 06 в новой папке с незанятым именем. Прежнюю папку и её файлы не перезаписывайте. После четырёх коммитов снова проверьте чистый git status, затем переходите к шагам ниже.

В этом упражнении первую правку коммитим до того, как вносим вторую: так проще сохранить два независимых результата отдельно. Если обе правки уже внесены в файл, один git add README.md захватит их обе — полный add неизменённого файла не разделит их.

Точный порядок действий:

1. Открыть README.md в редакторе, добавить строку Описание: учебный репозиторий, сохранить файл.
2. git diff — убедиться, что в выводе только эта строка.
3. git add README.md
4. git diff --staged — подтвердить, что в индексе именно эта правка и ничего лишнего.
5. git commit -m "Добавлено описание проекта в README"
6. Открыть README.md, добавить строку ## Навигация, сохранить файл.
7. git add README.md
8. git commit -m "Добавлен раздел навигации в README"

После шага 5 первая правка уже зафиксирована в коммите. Рабочая папка снова чистая. По выбранному порядку только после этого открываем файл и вносим вторую правку.

Ловушка одновременного внесения обеих правок. Если вы открыли файл и сразу добавили и строку с описанием, и строку с навигацией — а потом выполнили git add README.md, — в индекс попадёт текущее состояние файла целиком. Оба изменения окажутся в одном diff, и один коммит сохранит их вместе. Повторный git add без новой правки ничего не изменит: в индексе уже лежит тот же файл.

Последовательность «внести первую правку → закоммитить → внести вторую» — удобный способ избежать смешивания в этом упражнении. Это не единственная возможность получить два коммита; ограничение относится к полному add файла с двумя уже внесёнными правками без изменения его содержимого.

Проверка атомарности через git show

git show <ID> показывает diff коммита: какие строки добавлены (со знаком +) и какие удалены (со знаком -). Это тот самый инструмент, которым можно убедиться, что коммит содержит ровно одну правку — или обнаружить, что в него попало лишнее.

Порядок проверки. После создания двух коммитов запустите git log --oneline. Вывод будет примерно таким:

a3f1c2b Добавлен раздел навигации в README
7e804d1 Добавлено описание проекта в README
...

Скопируйте ID первого коммита и выполните:

git show 7e804d1

В разделе diff должна быть только одна добавленная строка — та, что с описанием:

+Описание: учебный репозиторий

Затем проверьте второй коммит:

git show a3f1c2b

Здесь должна быть только строка с навигацией:

+## Навигация

Если в diff одного коммита вы видите несвязанные фрагменты — строки из разных правок, которые логически не относятся друг к другу — это признак того, что коммит не атомарен. Один diff, одна задача — вот критерий.

git show работает с любым коммитом в истории, не только с последним. Это делает его удобным инструментом для аудита: можно взять любой старый коммит по ID из git log --oneline и проверить, что именно в нём лежит.