Как посмотреть различия между рабочими файлами, индексом и коммитом Git

Чтобы понять, что именно изменено в Git, недостаточно смотреть только на файл в редакторе. Один и тот же файл может одновременно существовать в трех состояниях: как он лежит в последнем коммите, как он подготовлен к следующему коммиту в индексе и как выглядит прямо сейчас в рабочей папке. Вопрос «какие у меня изменения?» на самом деле означает «между какими двумя состояниями я хочу увидеть разницу?».

Из-за этого у новичков часто возникает путаница: после git add команда git diff внезапно показывает меньше строк или вообще ничего не показывает, хотя файл точно менялся. Это не ошибка. Просто вы начали сравнивать уже не те две точки. Ниже разберем, как смотреть каждую разницу отдельно и как сверять их между собой, не трогая чужие изменения и ничего не откатывая.

Три состояния одного файла

Полезно держать в голове простую схему. Коммит — это последняя зафиксированная версия, обычно HEAD. Индекс — это снимок того, что попадет в следующий коммит. Рабочее дерево — это файлы, которые вы редактируете в каталоге проекта прямо сейчас.

Команды diff становятся понятными, если читать их как сравнение двух слоев. Обычный git diff показывает разницу между рабочими файлами и индексом: что вы уже изменили, но еще не добавили в staged. Команда git diff --cached сравнивает индекс с коммитом: что уже подготовлено к коммиту. А git diff HEAD показывает общую разницу между текущими файлами и последним коммитом, то есть итоговую картину без разделения на staged и unstaged.

Именно поэтому один и тот же файл может фигурировать сразу в двух diff. Например, вы изменили строку, добавили файл в индекс, а потом снова поправили тот же файл. В индексе уже лежит одна версия, а в рабочей папке — другая. Git умеет показывать обе разницы отдельно, и в этом его главная польза перед «просто списком измененных файлов».

Как увидеть изменения до добавления в индекс

Если вы редактировали файл, но еще не запускали git add, используйте git diff. Эта команда отвечает на вопрос: что отличается между тем, что у меня на диске, и тем, что сейчас подготовлено к коммиту? Пока вы ничего не staged, индекс обычно совпадает с последним коммитом, поэтому такой diff выглядит как «мои свежие правки».

Читать вывод лучше не по цветам, а по смыслу строк. Строки с минусом показывают, что было в точке сравнения «до», строки с плюсом — что стало «после». Если вам нужно проверить только один файл, добавьте путь после двойного дефиса:

git diff -- app.conf

Это удобно, когда в репозитории много параллельных изменений. Вы не распыляетесь на весь проект и видите только один участок работы. Если после правки вы сразу смотрите git diff, а затем делаете git add, полезно заметить момент перехода: часть различий «переедет» из обычного diff в staged-diff. Это нормальное поведение, а не потеря данных.

Как увидеть изменения после добавления в индекс

Когда вы уже выполнили git add, проверять подготовленный набор нужно командой git diff --cached. В некоторых версиях и подсказках вы увидите равнозначный вариант git diff --staged. Здесь вопрос другой: чем мой индекс отличается от последнего коммита?

Это особенно полезно перед коммитом. Вы можете редактировать большой файл частями, добавлять изменения в индекс по шагам и проверять именно то, что реально войдет в историю. Если после git add обычный git diff стал пустым, это значит лишь одно: рабочая копия сейчас совпадает с индексом. Но это не говорит, что изменений нет вообще. Их теперь нужно смотреть через --cached.

Есть и важный крайний случай: если первый коммит еще не создан, HEAD отсутствует. Тогда git diff --cached покажет все staged-изменения целиком. Для учебного репозитория это удобно: можно сразу понять, какой снимок вы собираетесь зафиксировать первым коммитом.

Учебный пример: как один файл попадает в два разных diff

Учебный пример. Ниже — полностью условный сценарий для локального учебного репозитория в обычном терминале с установленным Git. Цель не в том, чтобы выучить команды наизусть, а в том, чтобы увидеть две разные разницы у одного файла и не перепутать их.

Сначала создадим минимальный репозиторий и зафиксируем исходное состояние:

git init
printf "version=1\nmode=prod\n" > app.conf
git add app.conf
git commit -m "init"

Теперь меняем файл так, чтобы появились две правки:

printf "version=2\nmode=prod\ntimeout=30\n" > app.conf
git diff

На этом шаге git diff покажет две вещи относительно индекса: строка version=1 стала version=2, и появилась новая строка timeout=30. Это изменения до добавления.

Подготовим их к коммиту:

git add app.conf
git diff
git diff --cached

Теперь обычный git diff пустой, потому что рабочий файл совпадает с индексом. Зато git diff --cached покажет те самые две правки как содержимое будущего коммита.

Сделаем еще одну правку после добавления в индекс:

printf "version=2\nmode=dev\ntimeout=30\n" > app.conf
git diff
git diff --cached
git diff HEAD

И вот здесь начинается самое полезное. Обычный git diff покажет только изменение mode=prod на mode=dev, потому что именно этим рабочая копия отличается от индекса. Команда git diff --cached по-прежнему покажет только уже staged-правки: смену версии и добавление timeout=30. А git diff HEAD покажет полную картину относительно последнего коммита: и новую версию, и новый timeout, и смену режима на dev.

Проверяемый результат такой: один и тот же файл app.conf участвует в двух разных сравнениях одновременно. Если вы смогли объяснить словами, почему git diff и git diff --cached показывают разные куски одного файла, значит вы поняли механику индекса, а не просто запомнили команды.

Как сверить два diff и не запутаться

Практически удобнее идти в одном и том же порядке. Сначала смотрите git diff --cached и отвечайте себе: «что уже точно готово к коммиту?». Затем открывайте git diff и проверяйте: «что я еще не добавил?». И только после этого, если нужна общая картина, используйте git diff HEAD.

Такой порядок экономит время. Если начать сразу с общего diff против HEAD, вы увидите весь объем изменений, но не поймете, какая часть уже staged, а какая еще нет. Для одиночного учебного задания это терпимо, а в реальной работе легко приводит к лишним коммитам: вы думаете, что подготовили файл полностью, а часть строк осталась только в рабочей копии.

Закреплять этот навык лучше в коротком упражнении на одном файле, а не на большом проекте. Если вы выбираете обучение, задайте себе три вопроса. Есть ли в программе отдельная тема про индекс, а не только про коммиты? Есть ли самостоятельная практика, где один файл меняют и до, и после git add? Есть ли проверка результата: должен ли студент объяснить различие между git diff и git diff --cached своими словами, а не просто перечислить команды?

Если нужен связанный курс по теме, в сохраненном описании каталога курса «Профессия DevOps-инженер с нуля + ИИ» есть модуль по Git с темами «Индекс и частичные коммиты» и «Сравнение версий». Для этой статьи это релевантно не из-за названия профессии, а потому что навык чтения diff напрямую опирается на понимание индекса и разницы между слоями состояния файла.