Git для начинающих: смотрим изменения и отменяем ошибки. Урок 3

Перед коммитом полезно увидеть, что именно вы сохраняете. А когда ошибка уже случилась, сначала стоит понять её положение: файл просто изменён, уже подготовлен через git add или записан в историю? От этого зависит действие.

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

Шаг 1. Готовим понятный исходный файл

cd ~/git-lessons/my-first-project
git status

Если есть незавершённые правки, сначала сохраните нужные изменения. С чистым состоянием переключаемся в main:

git switch main
notepad plan.txt

Создаём новый учебный файл plan.txt с двумя строками:

Подготовить текст.
Проверить перед публикацией.

Если plan.txt уже занят вашим файлом, выберите другое имя и замените его во всех командах урока. Не перезаписывайте свои материалы ради примера.

Сохраняем через Ctrl + S и закрываем файл. Записываем исходное состояние:

git add plan.txt
git commit -m "Добавил исходный план"
git status

Ожидаем чистый статус. У нас появилась точка, к которой будем возвращаться в упражнении. Если возникают ошибки с настройкой автора или созданием репозитория, нужная подготовка есть в первом уроке.

Шаг 2. Читаем изменения через git diff

Открываем plan.txt в Блокноте и заменяем вторую строку:

Подготовить текст.
Опубликовать без проверки.

Сохраняем файл, закрываем и смотрим:

git status
git diff -- plan.txt

В статусе появится изменённый файл, а в разнице — строки примерно такого вида:

 Подготовить текст.
-Проверить перед публикацией.
+Опубликовать без проверки.

Минус в начале означает прежнюю строку, плюс — новую. Это отметки вывода Git: в сам файл их добавлять не нужно. Строки с пробелом в начале показывают окружающий текст без изменения. Заголовки ---, +++ и строка с @@ обозначают сравниваемые файлы и участок изменения.

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

Когда результат открыт в просмотрщике, выход — клавиша q.

Шаг 3. Отменяем правку, которую ещё не готовили к коммиту

Мы намеренно внесли неудачное изменение и хотим вернуть сохранённый план.

Следующая команда перезапишет текущий plan.txt версией последнего коммита. Нужные незакоммиченные правки заранее скопируйте в другой файл. В упражнении отменяем только нашу учебную замену строки. Закройте файл в Блокноте перед восстановлением.

git restore --source=HEAD --worktree -- plan.txt
cat plan.txt
git status

Должна вернуться строка «Проверить перед публикацией.», а статус — стать чистым. Здесь HEAD означает текущий последний коммит. История не поменялась: мы восстановили рабочий файл из сохранённой версии.

Шаг 4. Разбираемся, что меняется после git add

Снова заменим вторую строку на «Опубликовать без проверки.», сохраним и закроем файл. Затем выполним:

git add plan.txt
git diff -- plan.txt
git diff --cached -- plan.txt

Первая команда выбирает новое содержимое для коммита. После неё обычный git diff для этого файла ничего не покажет, если вы не меняли его ещё раз. Подготовленная версия уже совпадает с файлом на диске.

А git diff --cached показывает подготовленные изменения относительно последнего коммита. Здесь как раз увидим нашу замену строки.

Допустим, мы пока передумали включать файл в коммит, но хотим оставить новую строку на диске:

git restore --staged -- plan.txt
git status
git diff -- plan.txt

Теперь файл находится в Changes not staged for commit, а его новая строка сохранилась. --staged снимает подготовку; это не команда удаления текста из рабочего файла. Оба режима восстановления описаны в справке git restore.

Проверка проста: cat plan.txt всё ещё покажет «Опубликовать без проверки.». Подготовленный список можно проверить через git diff --cached -- plan.txt — он должен быть пустым.

Шаг 5. Намеренно записываем учебную ошибку в историю

Теперь разберём другой случай: ошибочная строка уже попала в коммит. Для упражнения сохраняем её специально:

git add plan.txt
git commit -m "Учебная ошибка: убрал проверку"
git status
git log --oneline -3

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

git diff HEAD~1 HEAD -- plan.txt

HEAD~1 здесь — родитель текущего коммита, а HEAD — последний коммит. В этой линейной истории увидим ту же замену правильной строки на ошибочную.

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

Шаг 6. Отменяем ошибочный коммит через revert

Поскольку ошибка уже записана в историю, создадим новый коммит с обратным изменением. Такой подход даёт git revert: исходная запись остаётся видна, а её действие отменяется отдельной записью. Это описано в справке git revert.

Перед выполнением проверьте git status: рабочая папка должна быть чистой. В нашем упражнении отменяем последний обычный коммит, который только что создали:

git revert --no-edit HEAD

--no-edit оставляет предложенное Git сообщение и не открывает редактор. Это важно: отдельный git commit после успешного выполнения уже не нужен.

Проверяем:

cat plan.txt
git log --oneline -3
git status

В файле снова должна быть строка «Проверить перед публикацией.». В истории будут три последовательных события: исходный план, учебная ошибка и отмена ошибки. Статус должен быть чистым.

Команда с HEAD рассчитана на этот точный момент упражнения. В своём проекте сначала проверяйте git log, чтобы не отменить другой последний коммит. Отмена коммитов слияния и конфликтующие отмены требуют отдельного разбора.

Если вместо завершения Git сообщил о конфликте, не запускайте revert повторно. Посмотрите git status. Пока отмена находится в процессе, команда git revert --abort позволяет прекратить именно эту попытку. Затем можно разобраться в причинах; способ чтения конфликтующих строк покажем в следующем уроке.

Как выбрать нужное действие

Если вы уже подготовили файл через git add и решили полностью отменить его правки, сначала снимите подготовку через git restore --staged -- plan.txt, затем восстановите рабочий файл из HEAD. Перед вторым действием сохраните нужный текст отдельно. Такой порядок не оставит в подготовке старую ошибочную версию.

Почему иногда «ничего не происходит»

Обычный diff пустой, хотя я менял текст. Проверьте git status и git diff --cached. Возможно, вы уже выполнили git add. Ещё одна причина — файл не сохранён в редакторе или вы редактируете другую папку.

После --staged строка не исчезла. Так и должно быть: снята подготовка к коммиту, рабочее содержимое осталось. Для возврата файла используется другой режим из шага 3, с предупреждением о перезаписи.

Git не видит новый файл через diff. Посмотрите блок Untracked files в git status. Сначала прочитайте новый файл в редакторе; чтобы увидеть его как подготовленное добавление, используйте git add имя_файла и затем git diff --cached.

Команды показывают слишком много текста. Указывайте нужное имя после --, как в примерах. Из просмотрщика выходите через q.

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

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

Сверено с официальной документацией 3 ноября 2026 года. Сценарии diff, снятия подготовки, восстановления и revert проверены в отдельном локальном репозитории.

Все уроки курса «Git с нуля»

1. Установка и первый бэкап
2. Ветки и объединение изменений
3. Просмотр изменений и отмена ошибок
4. Конфликт слияния по шагам
5. Какие файлы исключать: .gitignore