Меню

Git сравнить два коммита



git diff — учимся сравнивать в Git

April 16, 2015

Краткий обзор команды git diff

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

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

Когда изменение обнаружено, тогда можно решать, что с ним делать — оставить, удалить или отредактировать.

Перед использованием команды стоит напомнить о трех состояниях системы Git: Working Area, Staging Area, Repository. Фактически, команда производит сравнение между разными состояниями одного файла.

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

Working Area

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

Но изменения в этом файле не индексируются ( ) и не фиксируются ( ).

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

В этом случае производится сравнение между фиксированной версией файла (в области Repository) и его измененной версией (в области Working Area).

Вывод будет примерно таким:

В этом примере все предельно ясно и понятно. Строка — это фиксированная версия файла . Строка — это измененная версия файла .

… отображают, сколько и каких строк удалено (знак минус); сколько и каких строк добавлено (знак плюс).

Итак, с первым вариантом разобрались. Комадна выполняет сравнение версии файла из области Repository и этой же версии из области Working Area.

Staging Area

Второй вариант — файл отслеживается, в него внесено изменение, которое проиндексировано (внесено в область Staging Area).

Команда ничего не покажет, так как изменения в файле были перенесены ( ) из области Working Area в область Staging Area. Другими словами, область Working Area чистая и в ней нет ничего, чтобы можно было сравнить с областью Repository.

В этом случае для команды необходимо добавить ключ . Тогда вывод будет примерно таким:

Ключ указывает, что необходимо сравнивать область Repository с областью Staging Area.

Итак, разобрались со вторым случаем. Команда производит сравнение области Repository с областью Staging Area.

Repository

Третий вариант — файл отслеживается, в него внесены изменения, которые проиндексированы ( ) и зафиксированы ( ).

В этом случае область Working Area и Staging Area чистые от изменений, поэтому область Repository нельзя сравнивать с ними — там нет ничего для сравнения.

Поэтому команда или ничего не покажет — сравнивать то не с чем!

Читайте также:  Rtx 2080 max q сравнение

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

В этом случае команда сравнения будет выглядеть примерно таким образом:

Здесь — это первые семь символов hash-суммы последнего commit’а, — первые семь символов hash-суммы предпоследнего commit’а.

Их можно получить командой:

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

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

Angular — именованные outlets

Для меня немного запутанная картина с именованными областями отображения и главное — с правильной настройкой. Нужно немного прояснить для. … Continue reading

Источник

Git сравнить два коммита

Вы можете генерировать diff между любыми двумя версиями вашего проекта используя git diff:

Это сгенерирует diff между последними коммитами двух ветвей разработки. Если вы предпочитаете найти diff от их общего предка к ветке test, вы можете использовать три точки вместо двух:

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

Что вы будете коммитить

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

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

что покажет вам различия между индексом и вашим последним коммитом; то что вы бы закоммитили, если выполнили коммит командой «git commit» без параметра «-a». В заключении вы можете выполнить

что покажет изменения в рабочей директории от последнего коммита; то что вы бы закоммитили если выполнили команду «git commit -a».

Больше параметров Diff

Если вы хотите увидеть как ваша рабочая директория отличается от состояния проекта в другой ветке, то выполните команду

Это покажет вам что именно отличается между вашей рабочей директорией и снапшотом в ветке ‘test’. Вы также можете ограничить сравнение определенным файлом или поддиректорией добавив path limiter (ограничитель пути):

Эта команда покажет вам изменения между вашей рабочей директорией и последним коммитом (или, если быть более точным, концом текущей ветки, ограничивая сравнение файлами в поддиректории ‘lib’.

Если вы не хотите видеть весь патч, вы можете добавить параметр ‘—stat’, которые ограничит вывод списком файлов с изменениями и с кратким текстовым графическим описанием сколько строк изменилось в каждом файле..

Читайте также:  Состояние рынка это сравнения

Иногда полезно увидеть общие изменения чтобы освежить память.

Источник

Команда Git diff. Как сравнивать изменения в Git

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

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

Команда выводит изменения в файлах, которые еще не были добавлены в индекс. Сравнение происходит с последним коммитом.

Сравнение с последним коммитом, включая файлы в индексе

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

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

Команда git diff позволяет сравнивать два различных коммита. Сначала нужно определить хеш (ID) коммитов, которые требуется сравнивать. Можно воспользоваться командой git log, чтобы вывести список коммитов и их идентификаторы:

Теперь сравним два коммита. Для этого в качестве первого аргумента команде git diff указывается хеш первого коммита, а вторым аргументом хеш второго коммита, например:

Сравнение двух веток

Для вывода всех изменений между концами двух веток, необходимо для git diff указать имена веток:

Сравнение файлов между двумя ветками

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

Вместо branch1, branch2 нужно указать название веток, а вместо myfile.cpp путь до сравниваемого файла. Через пробел можно добавить еще файлы для сравнения.

Исключить некоторые файлы из сравнения

Иногда нужно выполнить git diff , но исключить один или несколько файлов, чтобы команда git diff их проигнорировала. Для этого используется запись вида ’:(exclude)имя_файла’ или короткая запись ’:!имя_файла’

Или более короткая запись:

Сравнивать только изменения в файлах (игнорировать новые и удаленные файлы)

Чтобы исключить из сравнения новые и удаленные файлы, можно воспользоваться опцией —diff-filter , которая позволяет выбирать какие именно изменения (файлы) нужно сравнивать.

Чтобы выполнить сравнение только изменений внутри файлов (игнорируя новые, удаленные, переименованные файлы) используется ключ Modified (M) — —diff-filter=M :

Источник

Git сравнить два коммита

git diff COMMIT позволяет сравнивать изменения, находящиеся в разных коммитах или ветках. Также передавать можно HEAD и тэги. Нужные значения указываются вместо COMMIT в примере.

Сравнение файлов между двумя коммитами ( git diff commit)

Каждый коммит в git имеет свой идентификатор, который можно выявить при помощи git log.

Идентификатор можно передать git diff

Читайте также:  Как раскрыть роль сравнения

Как найти идентификатор коммита

git log —pretty=onelinegit log —pretty=oneline

294276ecd27183dbfa464c45b41cfe1c24082ba0 (HEAD -> master, origin/master) added readme
d4cc089501fb2a9c64eb0454fe2e6c2205f1e527 added readme
b467651fe47da55118e138e52dd4c1f41e6f2983 ready to go

git log выводит идентификатор и добавленный при коммите комментарий.

По умолчанию сравнение выполняется с текущим состоянием, достаточно передать ID

git diff ufihj09kik123030c389545fgf54452265545455f102

diff —git a/README.md b/README.md
index 5d1ae95..41c1db5 100644
— a/README.md
+++ b/README.md
+
+### How to use ###
…skipping…

\ No newline at end of file

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

Между двумя коммитами

Таким же образом передается через пробел два идентификатора коммитов

git diff d4cc089501fb2a9c64eb0454fe2e6c2205f1e527 b467651fe47da55118e138e52dd4c1f41e6f2983

diff —git a/README.md b/README.md
index 5d1ae95..486813d 100644
— a/README.md
+++ b/README.md

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

Файл передается после идентификатора через двоеточие

Источник

Git compare: быстрый способ сравнить две ветки

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

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

В результате локальная ветка законченной задачи выглядит примерно так:

Наступает следующий этап:

1) Все коммиты из задачи объединяются в один большой ( feature-all-private на картинке)

2) Этот большой коммит разбивается на аккуратные коммиты с внятными описаниями ( feature-public на картинке):

Проблема: во время разбития коммитов я обычно провожу легкий рефекторинг, меняю коммиты местами и прочее, что потенциально может привести к незапланированным изменениям в коде (что-то потерялось при ребейзе или разрешении конфликтов, например)

Решение: в гите на тот момент не было инструмента быстро сравнить содержимое двух веток, поэтому я решил написать небольшой скрипт — git-cmp
Инструкция по установке достаточно простая — нужно локально сохранить bash-скрипт и добавить алиас в гите.
Теперь мы можем одной командой сравнить «рабочую» версию задачи ( feature-private ) с конечной «публикуемой» версией ( feature-public ):

Вывод которой покажет, что либо изменений нет и ветки идентичны:

Либо изменения есть и они будут показаны с использованием git-diff :

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

Надеюсь, этот скрипт будет полезен кому-то еще
Исходники выложены на гитхабе
Картинки были созданы с помощью codepen.io

Update: Оказывается, такая функциональность уже реализована в стандартном наборе гита и называется git-diff

Источник