Что такое git diff
Вы можете генерировать diff между любыми двумя версиями вашего проекта используя git diff:
Это сгенерирует diff между последними коммитами двух ветвей разработки. Если вы предпочитаете найти diff от их общего предка к ветке test, вы можете использовать три точки вместо двух:
git diff это невероятно полезный инструмент для нахождения изменений между любыми двумя точками в истории вашего проекта, или чтобы увидеть что другие разработчики пытаются вносить в новые ветви. и т.д.
Что вы будете коммитить
Вы будете обычно использовать git diff для нахождения различий между последним коммитом, вашем индексом, и вашей рабочей директории. Это просто сделать выполнив
Это покажет изменения в вашей рабочей директории которые еще не были добавлены в индекс для последующего коммита. Если вы хотите видеть что в индексе готово для коммита то выполните
что покажет вам различия между индексом и вашим последним коммитом; то что вы бы закоммитили, если выполнили коммит командой «git commit» без параметра «-a». В заключении вы можете выполнить
Больше параметров Diff
Если вы хотите увидеть как ваша рабочая директория отличается от состояния проекта в другой ветке, то выполните команду
Это покажет вам что именно отличается между вашей рабочей директорией и снапшотом в ветке ‘test’. Вы также можете ограничить сравнение определенным файлом или поддиректорией добавив path limiter (ограничитель пути):
Эта команда покажет вам изменения между вашей рабочей директорией и последним коммитом (или, если быть более точным, концом текущей ветки, ограничивая сравнение файлами в поддиректории ‘lib’.
Если вы не хотите видеть весь патч, вы можете добавить параметр ‘—stat’, которые ограничит вывод списком файлов с изменениями и с кратким текстовым графическим описанием сколько строк изменилось в каждом файле..
Иногда полезно увидеть общие изменения чтобы освежить память.
Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
April 16, 2015
Краткий обзор команды git diff
Перед использованием команды diff стоит напомнить о трех состояниях системы Git: Working Area, Staging Area, Repository. Фактически, команда diff производит сравнение между разными состояниями одного файла.
Working Area
Но изменения в этом файле не индексируются ( git add ) и не фиксируются ( git commit ).
В этом случае, чтобы увидеть изменения, нужно запустить команду:
В этом случае производится сравнение между фиксированной версией файла index.html (в области Repository) и его измененной версией (в области Working Area).
Вывод будет примерно таким:
… отображают, сколько и каких строк удалено (знак минус); сколько и каких строк добавлено (знак плюс).
Итак, с первым вариантом разобрались. Комадна git diff выполняет сравнение версии файла из области Repository и этой же версии из области Working Area.
Staging Area
Команда git diff ничего не покажет, так как изменения в файле index.html были перенесены ( git add ) из области Working Area в область Staging Area. Другими словами, область Working Area чистая и в ней нет ничего, чтобы можно было сравнить с областью Repository.
Repository
Так как все изменения зафиксированы и перенесены в область Repository, то и сравнивать их между собой нужно только там, в этой области.
В этом случае команда сравнения git diff будет выглядеть примерно таким образом:
Их можно получить командой:
Команда Git diff. Как сравнивать изменения в Git
Сравнение с последним коммитом
Для вывода изменений в файлах по сравнению с последним коммитом, используется git diff без параметров:
Команда выводит изменения в файлах, которые еще не были добавлены в индекс. Сравнение происходит с последним коммитом.
Сравнение с последним коммитом, включая файлы в индексе
Сравнение коммитов
Команда git diff позволяет сравнивать два различных коммита. Сначала нужно определить хеш (ID) коммитов, которые требуется сравнивать. Можно воспользоваться командой git log, чтобы вывести список коммитов и их идентификаторы:
Теперь сравним два коммита. Для этого в качестве первого аргумента команде git diff указывается хеш первого коммита, а вторым аргументом хеш второго коммита, например:
Сравнение двух веток
Для вывода всех изменений между концами двух веток, необходимо для git diff указать имена веток:
Сравнение файлов между двумя ветками
Чтобы сравнить конкретные файлы между двумя ветками используется команда:
Вместо branch1, branch2 нужно указать название веток, а вместо myfile.cpp путь до сравниваемого файла. Через пробел можно добавить еще файлы для сравнения.
Исключить некоторые файлы из сравнения
Или более короткая запись:
Сравнивать только изменения в файлах (игнорировать новые и удаленные файлы)
Анализ сделанных изменений — Введение в Git
Во время разработки программистам часто приходится останавливаться и анализировать изменения, которые они сделали с последнего коммита. Потребность смотреть изменения становится очевидной, если представить себе, что такое работа над реальным проектом. Как правило, это тысячи (десятки и сотни тысяч) строк кода, сотни и тысячи файлов и иногда несколько дней работы. Потратив даже несколько часов в таком проекте, очень сложно вспомнить что и где менялось, а что ещё осталось поменять.
Анализировать изменения важно даже в небольших проектах. Прямо сейчас во время разработки этого курса изменилось несколько файлов и git status выглядит так:
Попробуем воспроизвести подобную ситуацию в нашем проекте. Выполним следующий код в репозитории hexlet-git:
Вывод команды поначалу может смутить. Здесь довольно много служебных данных, за которыми уже идут изменения. git diff выводит именно те строки, которые изменились (и иногда строки вокруг измененных для удобства анализа), а не файлы целиком. Слева от них ставится знак «—«, если строка была удалена, и «+» для добавленных строк.
git diff — команда, которую нужно обязательно запускать перед каждым коммитом. Она позволяет проанализировать добавляемые изменения и исправить возможные ошибки. Иногда программисты по ошибке добавляют в коммит то, что туда не должно попасть.
Самостоятельная работа
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
