Команда git diff: просмотр изменений в коде

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

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

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

git diff – универсальная diff-команда

Команда git diff выводит изменения между вашей текущей рабочей директорией и стейджингом.

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

Рассмотрим пример. Я создала Git-репозиторий cat_vs_dog. Нет, это не официальный репозиторий, но довольно серьезный)

Затем я создала два файла: cat.txt и dog.txt.

Каждый из файлов представляется нам:

Затем я поместила эти изменения в стейджинг при помощи команды

git add cat.txt dog.txt

Хотите убедиться, что они уже там? Используйте команду git status. Она покажет, какие изменения готовы к коммиту.

Допустим, после этого я захотела изменить имя собаки: вместо «puppy» назвать ее «pup».

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

Итак, я изменила «puppy» на «pup».

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

Для этого я запускаю команду git diff. Ниже вы можете видеть ее вывод.

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

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

Разбираем вывод git diff пошагово

Строка 1. Это две версии одного файла. Git называет их A (первая версия) и B (вторая версия).

• A – старая версия файла
• B – новая версия файла

Строка 2. Мета-данные файла. Они вряд ли вам пригодятся. Два первых числа — хеши двух сравниваемых файлов. 100644 — внутренний идентификатор режима файла.

Строка 3. Git приписал знак минус (-) версии A и знак плюс (+) версии B.

Строка 4. Обычно Git показывает не целый файл, а отрывки с измененными строками.

• Строка, начинающаяся с символа (-), взята из версии A
• Строка, начинающаяся с символа (+), взята из версии B

Помимо измененных строк вы также увидите строки кода до и после изменений — для понимания контекста.

Строка 5. Каждый отрывок начинается с заголовка. Заголовок обозначается символами @@ в начале и конце. Между ними идут два набора чисел. Видите -1 и +1?

• -1 означает, что из версии A извлечена одна строка, начиная со строки 1
• +1 означает, что из версии B извлечена одна строка, начиная со строки 1

Если бы у нас были наборы чисел -3,4 +3,2, тогда это означало бы следующее:

• -3,4 — из версии A извлечено 4 строки, начиная со строки 3
• +3,2 — из версии B извлечено 2 строки, начиная со строки 3

No newline at the end of the file. Эта фраза говорит нам о том, что после измененных строк других строк нет. То есть в этом примере я добавила только одну строку в файл и изменяла ее же. После нее ничего другого нет.

Время похвалить себя

Остановитесь на мгновение и похвалите себя за приложенные умственные усилия. Вы уже научились разбираться в выводе команды diff. Теперь, зная основы, можно легко изучить еще несколько команд…

От редакции Techrocks. Возможно, вас также заинтересует статья «Команда diff в Linux: сравниваем два файла».

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

Прежде чем сделать коммит, можно сравнить изменения, внесенные в стейджинг, с последним коммитом. Для этого нужно добавить флаг --staged или --cached. Мне нравится --staged, потому что он какой-то более осмысленный. Но если вы предпочитаете --cached, можете смело им пользоваться.

Давайте рассмотрим это на примере. Для начала сделаем коммит наших подготовленных (отправленных в стейджинг) изменений в репозиторий cat_vs_dog. Если не помните, что у нас в стейджинге, напомню: там файлы просто представляются как котенок и щенок (kitty и puppy).

Мы также хотели заменить «puppy» на «pup», но это изменение пока не в стейджинге.

Для начала сделаем коммит подготовленных изменений:

git commit -m "intro to cat and dog"

Теперь внесем в стейджинг изменение «puppy» на «pup». После этого запускаем команду git diff --staged. Она выведет разницу между стейджингом и последним коммитом.

• Версия A — последний коммит, содержащий строку «my name is puppy» в dog.txt
• Версия B — стейджинг, отличающийся от последнего коммита. «puppy» сменился на «pup» в dog.txt.

Из вывода diff мы видим, что именно мы изменили и внесли в стейджинг: в версии A было «my name is puppy», а в версии B у нас уже «my name is pup».

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

4 сравнения diff, которые стоит знать

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

Вы также можете запустить команду git diff <branch_name1> <branch_name2>, чтобы сравнить изменения в первой ветке с изменениями во второй. При сравнении веток порядок имеет значение, от него зависит то, что вы получите в выводе.

Примечание: сравнение веток затрагивает только коммиты. Другие изменения, как в стейджинге, так и нет, не учитываются.

Для сравнения двух коммитов можно использовать команду git diff <commit_hash> <commit_hash>. Как и при сравнении веток, здесь важен порядок указания коммитов.

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

• git diff HEAD <file_name>
• git diff <file_name>
• git diff --staged <file_name> или git diff --cached <file_name>
• git diff <branch_name1> <branch_name2> <file_name>
• git diff <commit_hash> <commit_hash> <file_name>

Заключение

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

Перевод статьи «Git diff Command – How to Compare Changes in Your Code».

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]