Git diff: чем сравнение двух веток отличается от трёх точек

git diff A B и git diff A..B сравнивают конечные состояния A и B. Запись git diff A...B сравнивает общего предка A и B с состоянием B. Три точки полезны, когда нужно посмотреть изменения второй ветки относительно точки расхождения.

На Mentoring.digital разберём ситуацию перед ревью. Ветки main и feature разошлись: в main появился отдельный служебный файл, а в feature изменился код задачи. Эти два вопроса требуют разных сравнений.

Две точки: что различается сейчас

git diff main feature
git diff main..feature
git diff --name-status main..feature

Первые две команды показывают одинаковое сравнение содержимого. Если файл добавлен только в main, он может выглядеть удалённым при переходе от состояния main к feature. Это ещё не означает, что автор feature удалял файл своим коммитом: файл мог никогда не присутствовать в этой ветке.

Порядок аргументов важен. В сравнении A B первый аргумент задаёт исходную сторону, второй конечную. Перестановка меняет направление добавлений и удалений.

Три точки: изменения от общего предка

git merge-base main feature
git diff main...feature
git diff --stat main...feature
git diff main...feature -- src/

merge-base выводит общий предок, выбранный Git. Сравнение с тремя точками показывает разницу между этим предком и feature. Изменения, сделанные только в main после расхождения, не входят в такую разницу.

Три точки несимметричны: feature...main отвечает уже на вопрос об изменениях main. При сложной истории с несколькими лучшими общими предками нужно отдельно проверить базу; не переносите упрощённую схему одной точки расхождения на любой граф коммитов.

Почему git log использует точки иначе

У diff задача сравнить содержимое двух конечных точек. У log задача выбрать коммиты. Поэтому значение диапазонов в git log нельзя механически перенести на git diff. Если нужен список коммитов ветки, смотрите историю; если нужен итоговый патч, смотрите diff с выбранной базой.

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

Порядок проверки перед ревью

1. Уточните целевую ветку и актуальность локальных ссылок. Если репозиторий обновлялся другими участниками, сначала получите разрешённые обновления из remote.
2. Посмотрите общий предок и убедитесь, что выбрали правильную пару веток.
3. Начните с --name-status или --stat, затем прочитайте полный патч.
4. Отдельно проверьте потенциальное слияние и тесты. Патч с тремя точками не доказывает отсутствие конфликтов.

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

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