Просмотр изменений в Git с помощью git diff

17 декабря 2025

Автор

Олег Марков

Введение

Команда git diff — один из главных инструментов Git для просмотра изменений. С ее помощью вы можете увидеть, что именно изменилось в файлах: какие строки были добавлены, какие удалены, какие участки кода переписаны.

Смотрите, я покажу вам, как через git diff можно:

проверить свои правки перед коммитом;
понять, чем отличается текущая ветка от другой;
посмотреть, что было изменено между двумя коммитами;
проанализировать конфликт слияния;
быстро найти, где именно «сломался» код.

Мы будем двигаться от простейших сценариев к более сложным. По ходу статьи вы увидите примеры команд, их вывод и пояснения, чтобы вам было проще сразу применять это в реальных проектах.

Основные режимы работы git diff

Сравнение рабочей директории с индексом (staging area)

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

Посмотреть неиндексированные изменения

Команда:

git diff

Показывает разницу между:

текущим состоянием файлов в рабочей директории;
и их состоянием в индексе (staging area).

То есть вы видите только те изменения, которые еще не были добавлены через git add.

Пример вывода:

diff --git a/main.go b/main.go
index 2c3a4b1..7d9e0f2 100644
--- a/main.go        // Старая версия файла
+++ b/main.go        // Новая версия файла
@@ -1,5 +1,6 @@
 func main() {
-    fmt.Println("Hello world")   // Эта строка была удалена
+    fmt.Println("Hello, world!") // Эта строка была добавлена
+    fmt.Println("Version 2")     // Еще одна добавленная строка
 }

Обратите внимание:

строки с - — удалены по сравнению с индексом;
строки с + — добавлены по сравнению с индексом;
строки без префиксов — контекст, чтобы вы понимали, где находится изменение.

Посмотреть индексированные изменения (то, что уже в staging)

Когда вы уже сделали git add и хотите увидеть, что именно пойдет в следующий коммит, используйте:

git diff --cached

или эквивалентную форму:

git diff --staged

Эта команда показывает разницу между:

индексом (staging area);
и последним коммитом (HEAD).

То есть здесь вы видите изменения, которые уже будут включены в коммит.

Посмотреть все изменения сразу

Если вы хотите увидеть и то, что уже добавлено в индекс, и то, что еще не добавлено, можно сравнить рабочую директорию напрямую с последним коммитом:

git diff HEAD

Теперь вы увидите суммарную разницу между текущими файлами и последним коммитом, игнорируя границу между «индексировано / не индексировано».

Сравнение с конкретным коммитом

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

Сравнение текущего состояния с коммитом

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

git diff <commit>

Например:

git diff 3a4f2c1

Здесь вы сравните:

текущую рабочую директорию (то, что у вас на диске сейчас);
с указанным коммитом.

Если хотите сравнить именно индекс с коммитом:

git diff --cached <commit>

Сравнение двух коммитов между собой

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

git diff <commit1> <commit2>

Например:

git diff 3a4f2c1 7b8d9e0

Смотрите, что тут происходит:

git берет состояние репозитория на коммит 3a4f2c1;
и сравнивает его с состоянием на коммит 7b8d9e0;
выводит разницу по всем затронутым файлам.

Можно использовать специальные ссылки:

HEAD~1 — предыдущий коммит;
HEAD~2 — два коммита назад и т.д.

Пример:

git diff HEAD~1 HEAD

Так вы увидите изменения только последнего коммита.

Сравнение веток

Когда работаете в команде, особенно важно понимать, чем одна ветка отличается от другой.

Базовое сравнение двух веток

Команда:

git diff main feature/login

Сравнивает состояние ветки main и ветки feature/login.

Важно: направление сравнения влияет только на то, где будут + и -:

git diff A B показывает, что нужно изменить в A, чтобы получить B;
строки с - — присутствуют в A, но отсутствуют в B;
строки с + — присутствуют в B, но отсутствуют в A.

Поэтому, если вы хотите увидеть, что добавила ваша ветка относительно main, удобно писать:

git diff main my-feature

Здесь добавленные строки (+) — это то, что ваша ветка привнесла по сравнению с main.

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

Часто бывает полезно посмотреть, что именно ваша ветка изменила по сравнению с тем моментом, когда она отвалилась от основной ветки. Для этого есть сокращенный синтаксис с ... (три точки):

git diff main...my-feature

Смотрите, как это работает:

Git ищет общий предок веток main и my-feature;
сравнивает этот общий предок с my-feature;
вы видите «чистые» изменения вашей ветки, без учета изменений, которые происходили в main параллельно.

Это особенно полезно перед созданием pull request, чтобы убедиться, что вы показываете именно свои изменения.

Формат вывода git diff

Структура заголовка diff

Посмотрим на типичный фрагмент вывода git diff:

diff --git a/app/config.yml b/app/config.yml
index 1a2b3c4..5d6e7f8 100644
--- a/app/config.yml    // Содержимое было таким
+++ b/app/config.yml    // Стало таким
@@ -10,6 +10,7 @@ server:
   port: 8080
-  timeout: 30           // Эта строка была удалена
+  timeout: 60           // Эта строка была добавлена
+  retries: 3            // Новая строка

Разберем:

diff --git a/... b/... — сравниваются две версии файла;
index ... — хэши содержимого файла до и после изменений;
--- и +++ — старая и новая версия файла;
блоки начинаются с строки @@ -<начало>,<количество> +<начало>,<количество> @@:
- левая часть (-...) — диапазон строк в старой версии;
- правая часть (+...) — диапазон в новой версии.

Строки внутри блока:

начинаются с пробела — контекст (строки не изменялись);
с - — удалены;
с + — добавлены.

Такой формат называется unified diff (объединенный формат). Он стандартен для многих инструментов и систем контроля версий.

Однострочное сравнение файлов

Иногда вам не важны детали по строкам — нужно только понять, какие файлы изменились, были добавлены или удалены.

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

git diff --name-only

Эта команда выведет список только имен файлов, в которых есть изменения.

Если нужны и тип изменений, и имена:

git diff --name-status

Пример вывода:

A src/new_module.go   // Добавлен файл
M src/main.go         // Изменен файл
D src/old_code.go     // Удален файл

Здесь:

A — Added (добавлен);
M — Modified (изменен);
D — Deleted (удален).

Расширенные режимы сравнения

Построчное и пословное сравнение

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

Опция --word-diff

Команда:

git diff --word-diff

Показывает отличия внутри строк. Пример:

- fmt.Println("Hello world")
+ fmt.Println("Hello, world!")

С использованием --word-diff может выглядеть так:

fmt.Println("Hello[- world-]{+ world!+}")

Здесь:

части в [- -] — удалены;
части в {+ +} — добавлены.

Если хотите более привычное выделение, есть вариация:

git diff --word-diff=plain

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

Ограничение сравнения только измененными строками

Иногда дифф получается очень большим, а вам нужно только увидеть сами отличия, без большого контекста.

Вы можете уменьшить количество контекстных строк:

git diff -U1      # по одной строке контекста вокруг изменений
git diff -U0      # без контекста, только измененные строки

Например:

git diff -U0 main.go

Так вы увидите только сами измененные строки, без соседних.

Игнорирование определенных типов изменений

Нередко дифф засорен несущественными изменениями: пробелами, переносами строк, форматированием. Git позволяет скрыть такие изменения.

Игнорировать пробелы в конце строки

git diff --ignore-space-at-eol

Git не будет считать изменением добавление или удаление пробелов в конце строки.

Игнорировать количество пробелов и табуляцию

git diff --ignore-space-change

Git будет считать строки одинаковыми, если в них различается только количество пробелов или табов между словами.

Полностью игнорировать все пробельные изменения

git diff --ignore-all-space

Здесь строки считаются одинаковыми, если совпадает порядок непробельных символов. Это удобно, если кто-то отформатировал код (таб → пробелы), а вы хотите увидеть только реальные логические изменения.

Сравнение, которое само выравнивает пробелы

Иногда проще использовать:

git diff -w

Эта опция эквивалентна --ignore-all-space, но более привычна и часто используется разработчиками.

Сравнение отдельных файлов и директорий

Иногда вам нужно посмотреть изменения не по всему проекту, а только по части.

Сравнение конкретного файла

git diff main.go

Покажет изменения в файле main.go между рабочей директорией и индексом.

Можно комбинировать с другими опциями:

git diff --cached main.go         // уже проиндексированные изменения
git diff HEAD main.go             // все изменения с последнего коммита
git diff 3a4f2c1 main.go          // изменения этого файла с указанным коммитом

Сравнение по директории

git diff src/

Сравнивает только файлы внутри каталога src.

Можно ограничить несколькими путями:

git diff HEAD src/ config/app.yml

Git сначала обрабатывает параметры команды (HEAD, опции), а потом пути. Файлы вне указанных путей показаны не будут.

Работа с контекстом коммитов и историей

Просмотр диффа конкретного коммита

Чтобы увидеть, что именно изменил один конкретный коммит, удобнее всего использовать git show:

git show <commit>

Например:

git show 7b8d9e0

По сути, это сочетание:

информации о коммите (автор, дата, сообщение);
и git diff между этим коммитом и его родителем.

Если хотите показать только diff без метаданных, можно добавить опцию:

git show --no-patch <commit>   // только заголовок без diff
git show --stat <commit>       // краткая статистика изменений

Но чаще всего достаточно обычного git show — там вы сразу видите и контекст коммита, и изменения.

Краткая статистика изменений

Иногда не нужен полный diff, а достаточно понять, в каких файлах были изменения и насколько они большие.

Команда:

git diff --stat

Покажет что-то вроде:

 src/main.go      | 10 +++++-----
 src/utils.go     |  3 ++-
 2 files changed, 7 insertions(+), 6 deletions(-)

Здесь:

для каждого файла показывается количество добавленных и удаленных строк;
внизу — суммарная статистика.

Это удобно, когда вы хотите оценить масштаб изменений перед обзором кода.

Анализ конфликтов слияния через git diff

Просмотр всех конфликтующих файлов

Когда вы делаете git merge или git rebase и получаете конфликты, git diff помогает разобраться, что именно нужно исправить.

Сначала можно посмотреть список конфликтующих файлов:

git diff --name-only --diff-filter=U

Опция:

--diff-filter=U выбирает только файлы в состоянии Unmerged (конфликты).

Просмотр конкретного конфликта

Теперь давайте разберемся на примере, как увидеть различия в одном конфликтующем файле.

Команда:

git diff

после неудачного merge покажет:

для конфликтных файлов — сложный diff, где видны обе версии (ваша и чужая).

Но удобнее смотреть только по одному файлу:

git diff path/to/conflicted_file.ext

Вы увидите фрагменты с маркерами:

<<<<<<< HEAD
// Вариант из вашей текущей ветки
fmt.Println("Hello from main")
=======
// Вариант из сливаемой ветки
fmt.Println("Hello from feature")
>>>>>>> feature/login

Сейчас вы видите маркеры в самом файле. А git diff показывает, как этот файл выглядит по сравнению с индексом (где все еще старая версия без конфликтных маркеров). Это помогает понять, какие части были добавлены в результате конфликта.

После ручного редактирования файла:

вы убираете маркеры <<<<<<<, =======, >>>>>>>;
выбираете один из вариантов или комбинируете их;
затем делаете git add для этого файла.

Потом можно проверить:

git diff --cached

Так вы увидите, как будет выглядеть результат разрешенного конфликта в коммите.

Частичное индексирование изменений (интерактивный diff)

Иногда в одном файле вы сделали несколько логически разных изменений и хотите закоммитить их по отдельности. Смотрите, я покажу вам, как это сделать с помощью git add -p.

Использование git add -p

Команда:

git add -p

Открывает интерактивный режим «по кусочкам» (hunk). Git покажет вам каждый блок изменений и предложит, что с ним делать.

Пример диалога:

@@ -10,6 +10,7 @@ func main() {
-    fmt.Println("Hello world")
+    fmt.Println("Hello, world!")
+    fmt.Println("Version 2")
Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?

Кратко о самых полезных опциях:

y — добавить этот блок в индекс;
n — пропустить этот блок;
a — добавить этот и все последующие блоки в этом файле;
d — пропустить этот и все последующие блоки в этом файле;
s — разбить блок на более мелкие (если это возможно).

Покажу вам типичный сценарий:

Запускаете git add -p.
Принимаете только те блоки, которые относятся к первой логической группе изменений.
Делаете коммит.
Повторяете для оставшихся блоков — второй коммит.

Так вы получаете более чистую историю коммитов, где каждый коммит решает свою задачу.

Просмотр диффа для конкретного этапа

После частичного индексирования полезно проверить, что именно сейчас находится в staging area:

git diff --cached

И отдельно можно посмотреть оставшиеся неиндексированные изменения:

git diff

Так вы легко контролируете процесс «разделения» правок.

Форматирование вывода и удобство чтения

Цветной вывод

Большинство современных Git-конфигураций уже включают цветной вывод, но если у вас по какой-то причине нет подсветки, вы можете включить ее явно:

git diff --color

Если хотите сделать это настройкой по умолчанию:

git config --global color.ui auto

Комментарии к этим командам:

git config --global color.ui auto
# Включаем автоматическую цветную подсветку для всех команд Git
# --global означает, что настройка применится для всех репозиториев текущего пользователя

Теперь diff всегда будет подсвечиваться цветом:

удаленные строки — красным;
добавленные — зеленым;
заголовки и контекст — другими цветами в зависимости от темы.

Постраничный вывод

Если дифф большой, его сложно просматривать в одной простыне. Git по умолчанию часто использует pager (обычно less). Если вдруг он у вас отключен, можно включить:

git config --global core.pager "less -FRSX"

Пояснение:

F — сразу показывает содержимое, если оно помещается на экран;
R — сохраняет управляющие последовательности (цвета);
S — отключает перенос строк;
X — не очищает экран после выхода.

Практические сценарии использования git diff

Проверка изменений перед коммитом

Один из самых полезных рабочих циклов выглядит так:

Пишете код.
Проверяете, какие файлы изменены:
```
git status
```
Смотрите подробный дифф:
```
git diff
```
Добавляете нужные файлы в индекс:
```
git add src/main.go
git add config/app.yml
```
Проверяете, что именно попадет в коммит:
```
git diff --cached
```

Делаете коммит:

git commit -m "Добавлена авторизация и обновлен конфиг"

Такой подход позволяет увидеть возможные опечатки, случайные изменения форматирования или временный отладочный код до того, как они попадут в репозиторий.

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

Представьте, что вы хотите слить ветку feature/payment в main. Перед merge полезно посмотреть, что эта ветка изменяет.

Команда:

git diff main...feature/payment

покажет именно те изменения, которые внесла ветка feature/payment, начиная от точки ответвления.

Если вы уже находитесь в main, можно использовать еще более простой вариант:

git diff main..feature/payment

Здесь:

.. (две точки) — простой diff между состояниями веток;
... (три точки) — сравнение ветки с их общим предком (чистые изменения ветки).

Заключение

Команда git diff — это гибкий инструмент для анализа изменений в репозитории на разных уровнях:

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

Вы можете комбинировать разные режимы:

git diff, git diff --cached, git diff HEAD — для контроля своих текущих правок;
git diff <commit1> <commit2> — для анализа эволюции кода;
git diff <branch1> <branch2> и git diff main...feature — для сравнения веток;
--name-only, --name-status, --stat — для краткого обзора;
-w, --ignore-space-change, --word-diff — для фильтрации и удобства чтения.

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

Частозадаваемые технические вопросы по теме и ответы

Как показать изменения только для уже закоммиченных данных без учета рабочей директории

Используйте сравнение коммитов или git log с параметрами:

git diff <old_commit> <new_commit>    # только разница между коммитами
git log -p                            # последовательность коммитов с diff

Так вы не будете затрагивать незакоммиченные изменения в рабочей директории.

Как сравнить файл в текущей ветке с тем же файлом в другой ветке

Укажите ветки и путь к файлу:

git diff main..feature/login -- path/to/file.go

Здесь вы увидите diff только для указанного файла, даже если в ветках изменилось много других файлов.

Как увидеть diff только по одному коммиту без остальных изменений

Используйте git show с указанием коммита и пути (если нужно сузить область):

git show <commit>               # diff всего коммита
git show <commit> -- file.go    # diff этого коммита только для file.go

Это удобно для локального анализа конкретного изменения.

Как исключить некоторые файлы или директории из diff

Можно воспользоваться возможностями .git/info/exclude или .gitignore, но для разового просмотра проще указать нужные пути явно и не включать ненужные:

git diff HEAD -- src/ tests/   # diff только по src и tests

Либо наоборот — использовать фильтрацию через grep по выводу diff, если знаете паттерны.

Как сохранить diff в файл и применить его в другом месте

Для сохранения:

git diff > changes.patch

Чтобы применить этот patch в другом клоне репозитория или на другой машине:

git apply changes.patch

Если patch сделан между коммитами (например, через git format-patch), для его применения можно использовать git am, чтобы сохранить коммитные метаданные.