Как увидеть изменения в файле git

Обновлено: 04.07.2024

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

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

Именно здесь на помощь приходит функция сравнения. Функция сравнения — это функция, которая принимает два входных значения и представляет изменения, существующие между этими источниками данных. Функции Diff могут выполняться для ветвей, файлов и коммитов.

В этом руководстве на примерах рассматриваются основы сравнения с Git и использование команды git diff. К концу чтения этого руководства вы станете экспертом в использовании команды git diff.

Команда Git Diff

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

Вот синтаксис команды git diff:

По умолчанию команда git diff отображает все незафиксированные изменения в вашем репозитории.

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

81 % участников заявили, что стали более уверенными в своих перспективах работы в сфере технологий после посещения учебного курса. Примите участие в тренировочном лагере сегодня.

Найдите подходящий вариант для буткемпа

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

Начните сменить профессию сегодня

Git Diff между коммитами

Вы можете сравнить файлы между двумя коммитами Git, указав имя ссылки, которая ссылается на коммиты, которые вы хотите сравнить. Ссылка может быть идентификатором коммита или HEAD, который указывает на текущую ветвь.

Давайте сравним две фиксации в нашем репозитории Git.

Для этого вам сначала нужно получить идентификаторы коммитов, файлы которых вы хотите сравнить. Вы можете выполнить эту задачу с помощью команды git log –pretty=oneline, которая возвращает краткую сводку всех коммитов в репозитории:

Эта команда возвращает:

Теперь предположим, что мы хотим сравнить эти две фиксации. Мы можем сделать это с помощью этой команды:

Приведенная выше команда выполнит операцию сравнения двух наших коммитов.

Git Diff между ветками

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

Care Karma подберет для вас лучшие учебные курсы по технологиям
Получайте эксклюзивные стипендии и подготовительные курсы

Предположим, мы хотим сравнить ветку «master» с веткой «dev-v0.9» в нашем репозитории. Мы могли бы сделать это с помощью этой команды:

При выполнении этой команды будет выполнено сравнение между ветвями «master» и «dev-v0.9» в нашей кодовой базе.

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

Предположим, мы хотим сравнить файл README.md в наших ветках «master» и «dev-v0.9». Мы могли бы сделать это, используя этот код:

Это сравнит файл README.md (который находится в нашем текущем каталоге, обозначенном синтаксисом «./») в ветвях «master» и «dev-v0.9».

Пример команды Git Diff

Предположим, мы инициализировали пустой репозиторий и хотим запустить наш репозиторий с файлом README.md. Мы создали файл README.md в нашем репозитории, который содержит следующее предложение:

Это пример функции сравнения Git.

Подготовка файлов и коммитов

Мы собираемся создать коммит с этим файлом, используя команду git commit:

Это позволяет нам сохранять внесенные нами изменения в наш репозиторий. Команда git возвращает:

Если мы запустим команду git diff на этом этапе, ничего не произойдет. Это связано с тем, что наш репозиторий был инициализирован, и между какими-либо файлами в нашем репозитории нет изменений. Теперь, когда у нас есть базовый репозиторий, мы можем изменить содержимое файлов в нашем репозитории. Это позволит нам увидеть команду git diff в действии.

Предположим, мы хотим добавить предложение «Мы только что добавили эту строку в наш файл». в файл README.md.Мы могли бы сделать это с помощью этой команды:

"Карма карьеры вошла в мою жизнь, когда я больше всего в ней нуждалась, и быстро помогла мне пройти буткемп. Через два месяца после выпуска я нашла работу своей мечты, которая соответствовала моим ценностям и целям в жизни!"

Венера, инженер-программист в Rockbot

Найдите подходящий вариант для буткемпа

Приведенная выше команда добавляет наше предложение в файл README.md.

Это означает, что теперь существует разница между нашим первоначальным файлом README.md и текущим файлом README.md в нашем репозитории.

Выполнив команду git diff, мы сможем увидеть различия между этими двумя файлами. По умолчанию команда git diff создает diff для всех файлов между последней фиксацией и текущим состоянием репозитория.

Выполнить сравнение Git между коммитами

Когда мы запускаем команду, возвращается следующий ответ:

Это пример функции сравнения Git.

Это типичный результат команды git diff. Наш результат показывает, что было добавлено или удалено в нашем файле в комбинированном формате различий.

Команда git diff возвращает список всех изменений во всех файлах между нашим последним коммитом и нашим текущим репозиторием.

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

В этом примере мы изменили только файл README.md, поэтому в любом случае будут показаны только эти изменения. Но если бы мы работали с большим репозиторием, мы могли бы захотеть сравнить только изменения в одном файле. Для этого мы могли бы использовать эту команду:

Эта команда позволяет нам сравнить нашу текущую версию файла README.md с последней версией, зафиксированной в нашем репозитории.

Разбивка различий в Git

Git diff содержит ряд компонентов, которые мы можем использовать для анализа изменений между файлами в репозитории. Давайте разберем их со ссылкой на наш предыдущий пример.

Входные файлы

Первым компонентом нашего сравнения являются входные файлы. Эта часть diff сообщает нам, какие файлы сравниваются в diff.

Мы сравниваем файл README.md в текущей версии нашего кода с файлом README.md в последней версии нашего кода. Это указано в первой строке нашего кода:

Метаданные

Далее наш diff содержит метаданные для нашего репозитория Git. Эти метаданные отображают метки версии объекта, используемые Git для отслеживания изменений, внесенных вами в файл.

Эта информация редко используется в большинстве случаев команды diff. В приведенном выше примере метаданные выглядят следующим образом:

Маркеры изменений

Эти маркеры сообщают нам, что были внесены изменения из a/README.md (обозначаются знаком минус), которые отражены в b/README.md (обозначается знаком плюс).

Изменения кода

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

Первая строка представляет собой сводку изменений, внесенных в наш файл. Это говорит нам о том, что мы добавили в наш файл одну строку кода (+1), начиная со второй строки (2).

Затем нам показывают список внесенных изменений. Как видите, поскольку мы добавили строку «Мы только что добавили эту строку в наш файл», эта строка появляется в нашем diff. Знак плюс говорит нам, что мы добавили эту строку в файл.

Заключение

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

В этом руководстве обсуждались основы сравнения с Git и использование команды git diff для выполнения операции сравнения. Теперь у вас есть все необходимые знания, чтобы начать использовать команду git diff на профессиональном уровне!

Дополнительные учебные материалы по Git см. в нашем руководстве How to Learn Git.

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

Помните, что каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: отслеживается или не отслеживается. Отслеживаемые файлы — это файлы, которые были в последнем моментальном снимке, а также любые недавно подготовленные файлы; они могут быть немодифицированными, модифицированными или поэтапными. Короче говоря, отслеживаемые файлы — это файлы, о которых Git знает.

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

Когда вы редактируете файлы, Git считает их измененными, поскольку вы изменили их с момента последней фиксации. В процессе работы вы выборочно размещаете эти измененные файлы, а затем фиксируете все эти поэтапные изменения, и цикл повторяется.

Проверка статуса ваших файлов

Основной инструмент, который вы используете для определения того, в каком состоянии находятся файлы, — это команда git status. Если вы запустите эту команду сразу после клона, вы должны увидеть что-то вроде этого:

Это означает, что у вас есть чистый рабочий каталог; другими словами, ни один из ваших отслеживаемых файлов не изменяется. Git также не видит неотслеживаемых файлов, иначе они были бы перечислены здесь. Наконец, команда сообщает вам, на какой ветке вы находитесь, и сообщает, что она не отклонилась от той же ветки на сервере. На данный момент эта ветвь всегда master , которая используется по умолчанию; вы не будете беспокоиться об этом здесь. Git Branching подробно расскажет о ветках и ссылках.

Допустим, вы добавили в проект новый файл, простой файл README. Если файла раньше не существовало, и вы запускаете git status , вы видите свой неотслеживаемый файл следующим образом:

Вы можете видеть, что ваш новый файл README не отслеживается, потому что он находится под заголовком «Неотслеживаемые файлы» в выводе статуса. Неотслеживаемый в основном означает, что Git видит файл, которого у вас не было в предыдущем моментальном снимке (фиксации) и который еще не был подготовлен; Git не начнет включать его в ваши снимки коммитов, пока вы явно не скажете ему об этом. Это делается для того, чтобы вы случайно не начали включать сгенерированные двоичные файлы или другие файлы, которые вы не хотели включать. Вы действительно хотите включить README , так что давайте начнем отслеживать файл.

Отслеживание новых файлов

Чтобы начать отслеживать новый файл, используйте команду git add . Чтобы начать отслеживать файл README, вы можете запустить это:

Если вы снова запустите команду состояния, вы увидите, что ваш файл README теперь отслеживается и готовится к фиксации:

Вы можете сказать, что это постановочное, потому что оно находится под заголовком «Изменения, которые необходимо зафиксировать». Если вы зафиксируете в этот момент, версия файла на момент запуска git add будет такой же, как и в последующем историческом моментальном снимке. Вы можете вспомнить, что когда вы запускали git init ранее, вы затем запускали git add — это должно было начать отслеживать файлы в вашем каталоге. Команда git add принимает путь либо к файлу, либо к каталогу; если это каталог, команда рекурсивно добавляет все файлы в этом каталоге.

Подготовка измененных файлов

Давайте изменим уже отслеженный файл. Если вы измените ранее отслеженный файл с именем CONTRIBUTING.md, а затем снова запустите команду git status, вы получите что-то вроде этого:

Файл CONTRIBUTING.md отображается в разделе «Изменения, не подготовленные для фиксации». Это означает, что отслеживаемый файл был изменен в рабочем каталоге, но еще не подготовлен. Чтобы подготовить его, вы запускаете команду git add. git add — это многоцелевая команда — вы используете ее, чтобы начать отслеживать новые файлы, создавать файлы и выполнять другие действия, такие как пометка файлов, конфликтующих слиянием, как разрешенных. Может быть полезно думать об этом больше как о «добавлении именно этого содержимого к следующему коммиту», а не о «добавлении этого файла в проект». Давайте сейчас запустим git add, чтобы подготовить файл CONTRIBUTING.md, а затем снова запустим git status:

Оба файла находятся в промежуточном состоянии и войдут в вашу следующую фиксацию. Теперь предположим, что вы помните одно маленькое изменение, которое хотите внести в CONTRIBUTING.md перед его фиксацией. Вы открываете его снова и вносите это изменение, и вы готовы зафиксировать. Однако давайте еще раз запустим git status:

Какого черта? Теперь CONTRIBUTING.md указан и как поэтапный и как неустановленный. Как это возможно? Оказывается, Git размещает файл точно так же, как когда вы запускаете команду git add. Если вы сделаете коммит сейчас, версия CONTRIBUTING.md, которая была, когда вы в последний раз запускали команду git add, будет использоваться в коммите, а не версия файла, как он выглядит в вашем рабочем каталоге, когда вы запускаете git commit . Если вы изменяете файл после запуска git add , вам нужно запустить git add еще раз, чтобы подготовить последнюю версию файла:

Краткий статус

Несмотря на то, что вывод состояния git довольно полный, он также довольно многословен. Git также имеет краткий флаг состояния, чтобы вы могли видеть свои изменения в более компактном виде. Если вы запустите git status -s или git status --short, вы получите гораздо более упрощенный вывод команды:

Новые файлы, которые не отслеживаются, помечаются знаком ??рядом с ними новые файлы, которые были добавлены в промежуточную область, имеют A , измененные файлы имеют M и так далее. На выходе есть два столбца: левый столбец указывает состояние промежуточной области, а правый столбец указывает состояние рабочего дерева. Так, например, в этом выводе файл README изменен в рабочем каталоге, но еще не подготовлен, а файл lib/simplegit.rb изменен и подготовлен. Rakefile был изменен, подготовлен и затем изменен снова, поэтому в нем есть изменения, которые являются как подготовленными, так и неустановленными.

Игнорирование файлов

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

Первая строка указывает Git игнорировать любые файлы, оканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут быть результатом сборки вашего кода. Вторая строка указывает Git игнорировать все файлы, имена которых заканчиваются на тильду ( ~ ), которая используется многими текстовыми редакторами, такими как Emacs, для пометки временных файлов. Вы также можете включить каталог log, tmp или pid; автоматически формируемая документация; и так далее. Настроить файл .gitignore для вашего нового репозитория перед тем, как начать, как правило, хорошая идея, чтобы вы случайно не зафиксировали файлы, которые вам действительно не нужны в вашем репозитории Git.

Правила для шаблонов, которые вы можете поместить в файл .gitignore, следующие:

Стандартные шаблоны глобусов работают и будут применяться рекурсивно ко всему рабочему дереву.

Вы можете начинать шаблоны с косой черты ( / ), чтобы избежать рекурсии.

Вы можете заканчивать шаблоны косой чертой ( / ), чтобы указать каталог.

Вы можете отменить шаблон, начав его с восклицательного знака ( ! ).

Шаблоны Glob похожи на упрощенные регулярные выражения, используемые оболочками. Звездочка ( * ) соответствует нулю или более символов; [abc] соответствует любому символу в квадратных скобках (в данном случае a, b или c); знак вопроса ( ? ) соответствует одному символу; а скобки, заключающие символы, разделенные дефисом (2), соответствуют любому символу между ними (в данном случае от 0 до 9). Вы также можете использовать две звездочки для соответствия вложенным каталогам; a/**/z будет соответствовать a/z , a/b/z , a/b/c/z и т. д.

Вот еще один пример файла .gitignore:

В простом случае репозиторий может иметь один файл .gitignore в корневом каталоге, который рекурсивно применяется ко всему репозиторию. Однако также возможно иметь дополнительные файлы .gitignore в подкаталогах. Правила в этих вложенных файлах .gitignore применяются только к файлам в каталоге, в котором они расположены. Репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore.

В задачу этой книги не входит детальное рассмотрение нескольких файлов .gitignore; подробности см. в man gitignore.

Просмотр поэтапных и неустановленных изменений

Если команда git status кажется вам слишком расплывчатой — вы хотите точно знать, что вы изменили, а не только то, какие файлы были изменены, — вы можете использовать команду git diff. Мы рассмотрим git diff более подробно позже, но вы, вероятно, будете использовать его чаще всего, чтобы ответить на эти два вопроса: что вы изменили, но еще не проиндексировали? И что вы инсценировали, что собираетесь совершить? Хотя git status отвечает на эти вопросы в общих чертах, перечисляя имена файлов, git diff показывает вам точные добавленные и удаленные строки — так сказать, патч.

Допустим, вы снова отредактировали и подготовили файл README, а затем отредактировали файл CONTRIBUTING.md, не подготовив его. Если вы запустите команду git status, вы снова увидите что-то вроде этого:

Чтобы увидеть, что вы изменили, но еще не подготовили, введите git diff без других аргументов:

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

Если вы хотите увидеть, что вы подготовили для следующего коммита, вы можете использовать git diff --staged . Эта команда сравнивает ваши поэтапные изменения с вашей последней фиксацией:

Важно отметить, что git diff сам по себе не показывает все изменения, сделанные с момента вашего последнего коммита, а только те изменения, которые еще не подготовлены. Если вы подготовили все свои изменения, git diff ничего не выдаст.

Для другого примера, если вы подготовите файл CONTRIBUTING.md, а затем отредактируете его, вы можете использовать git diff, чтобы увидеть изменения в файле, которые были подготовлены, и изменения, которые не были подготовлены. Если наша среда выглядит так:

Теперь вы можете использовать git diff, чтобы увидеть, что еще не обработано:

и git diff --cached, чтобы увидеть, что вы подготовили на данный момент ( --staged и --cached являются синонимами):

Мы продолжим использовать команду git diff различными способами в оставшейся части книги. Есть еще один способ посмотреть на эти различия, если вместо этого вы предпочитаете графическую или внешнюю программу просмотра различий. Если вы запустите git difftool вместо git diff , вы сможете просматривать любые из этих различий в таких программах, как emerge, vimdiff и многих других (включая коммерческие продукты). Запустите git difftool --tool-help, чтобы узнать, что доступно в вашей системе.

Фиксация ваших изменений

Теперь, когда ваша тестовая область настроена так, как вы хотите, вы можете зафиксировать свои изменения. Помните, что все, что еще не проиндексировано — любые созданные или измененные вами файлы, которые вы не запускали с помощью git add с тех пор, как вы их редактировали, — не войдет в эту фиксацию. Они останутся в виде измененных файлов на вашем диске. В этом случае предположим, что когда вы в последний раз запускали git status , вы видели, что все было подготовлено, поэтому вы готовы зафиксировать свои изменения. Самый простой способ зафиксировать — набрать git commit :

При этом запускается выбранный вами редактор.

Это задается переменной среды EDITOR вашей оболочки — обычно это vim или emacs, хотя вы можете настроить его как угодно, используя команду git config --global core.editor, как вы видели в разделе «Начало работы».

В редакторе отображается следующий текст (в этом примере показан экран Vim):

Вы можете видеть, что сообщение фиксации по умолчанию содержит последние выходные данные команды git status, закомментированные, и одну пустую строку сверху. Вы можете удалить эти комментарии и ввести сообщение о коммите или оставить их там, чтобы лучше помнить, что вы делаете.

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

Когда вы выходите из редактора, Git создает вашу фиксацию с этим сообщением фиксации (с удаленными комментариями и различиями).

Кроме того, вы можете напечатать сообщение фиксации вместе с командой фиксации, указав его после флага -m, например:

Теперь вы создали свой первый коммит! Вы можете видеть, что фиксация предоставила вам некоторую информацию о себе: какую ветку вы зафиксировали ( master ), какую контрольную сумму SHA-1 имеет фиксация ( 463dc4f ), сколько файлов было изменено и статистику о строках, добавленных и удаленных в зафиксировать.

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

Пропуск области подготовки

Хотя это может быть удивительно полезно для создания коммитов именно так, как вы хотите, область подготовки иногда немного сложнее, чем вам нужно в вашем рабочем процессе. Если вы хотите пропустить промежуточную область, Git предоставляет простой ярлык. Добавление параметра -a к команде git commit заставляет Git автоматически публиковать каждый файл, который уже отслежен, перед выполнением фиксации, позволяя вам пропустить часть git add:

Обратите внимание, что в этом случае вам не нужно запускать git add для файла CONTRIBUTING.md перед фиксацией. Это потому, что флаг -a включает все измененные файлы. Это удобно, но будьте осторожны; иногда этот флаг заставит вас включить нежелательные изменения.

Удаление файлов

Чтобы удалить файл из Git, вы должны удалить его из отслеживаемых файлов (точнее, удалить его из своей промежуточной области), а затем зафиксировать. Команда git rm делает это, а также удаляет файл из вашего рабочего каталога, чтобы в следующий раз вы не увидели его как неотслеживаемый файл.

Если вы просто удалите файл из своего рабочего каталога, он появится в области «Изменения, не подготовленные для фиксации» (то есть не подготовленные) вашего вывода статуса git:

Затем, если вы запустите git rm , он поэтапно удалит файл:

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

Еще одна полезная вещь, которую вы можете сделать, это оставить файл в рабочем дереве, но удалить его из области подготовки. Другими словами, вы можете захотеть сохранить файл на жестком диске, но Git больше не будет его отслеживать. Это особенно полезно, если вы забыли добавить что-то в свой файл .gitignore и случайно подставили его, например, большой файл журнала или кучу скомпилированных файлов .a. Для этого используйте параметр --cached:

Команде git rm можно передавать файлы, каталоги и шаблоны файловых шаблонов. Это означает, что вы можете делать такие вещи, как:

Обратите внимание на обратную косую черту ( \ ) перед * .Это необходимо, потому что Git выполняет собственное расширение имени файла в дополнение к расширению имени файла вашей оболочки. Эта команда удаляет все файлы с расширением .log в каталоге log/. Или вы можете сделать что-то вроде этого:

Эта команда удаляет все файлы, имена которых заканчиваются на ~ .

Перемещение файлов

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

Поэтому немного сбивает с толку наличие в Git команды mv. Если вы хотите переименовать файл в Git, вы можете запустить что-то вроде:

и это работает нормально. На самом деле, если вы запустите что-то подобное и посмотрите на статус, вы увидите, что Git считает это переименованным файлом:

Однако это эквивалентно запуску чего-то вроде этого:

Git неявно определяет, что это переименование, поэтому не имеет значения, переименовываете ли вы файл таким образом или с помощью команды mv. Единственная реальная разница в том, что git mv — это одна команда вместо трех — это функция удобства. Что еще более важно, вы можете использовать любой инструмент, который вам нравится, для переименования файла и обращения к add/rm позже, до фиксации.

Для продвижения проекта требуется множество небольших изменений. Понимание каждого из этих отдельных изменений является ключом к пониманию того, как развивался проект.
Хотя такие команды, как "git status" или обычная команда "git log", информируют вас только на очень широком уровне, существуют и другие команды, которые отображают изменения в деталях.

Шпаргалка Git

Не нужно запоминать все эти команды и параметры: получите нашу популярную «Шпаргалку по Git» — бесплатно!

Чтение различий

В управлении версиями различия между двумя версиями представлены в так называемом "различии" (или, как синоним, "исправлении"). Давайте подробно рассмотрим такой diff и научимся его читать.

Сравнение файлов a/b

Наш diff сравнивает два элемента друг с другом: элемент A и элемент B. В большинстве случаев A и B будут одним и тем же файлом, но в разных версиях. Хотя это не очень часто используется, diff также может сравнивать два совершенно не связанных файла друг с другом, чтобы показать, чем они отличаются.
Чтобы прояснить, что на самом деле сравнивается, вывод сравнения всегда начинается с объявления того, какие файлы представлены буквами "A" и "B".

Метаданные файла

Приведенные здесь метаданные файла представляют собой очень техническую информацию, которая вам, вероятно, никогда не понадобится на практике. Первые два числа представляют собой хэши (или, проще говоря, «идентификаторы») наших двух файлов: Git сохраняет каждую версию не только проекта, но и каждого файла как объекта. Такой хэш идентифицирует файловый объект в определенной версии. Последнее число — это внутренний идентификатор файлового режима (100644 — это просто «обычный файл», 100755 — исполняемый файл, а 120000 — символическая ссылка).

Маркеры для a/b

Далее в выходных данных фактические изменения будут помечены как исходящие от A или B. Чтобы отличить их друг от друга, каждому A и B назначается символ: для версии A это минус ("-" ), а для версии B используется знак плюс ("+").

Фрагмент

Сравнение не показывает весь файл от начала до конца: вы не хотели бы видеть все в файле из 10 000 строк, когда изменились только 2 строки. Вместо этого он показывает только те части, которые были фактически изменены. Такая часть называется «кусок» (или «кусок»). В дополнение к фактически измененным строкам фрагмент также содержит немного «контекста»: некоторые (неизмененные) строки до и после модификации, чтобы вы могли лучше понять, в каком контексте произошло это изменение.

Заголовок фрагмента

Каждому из этих фрагментов предшествует заголовок. Заключенный в два знака «@» каждый, Git сообщает вам, какие строки были затронуты. В нашем случае в первом чанке представлены следующие строки:

Из файла A (обозначенного знаком "-") извлекаются 6 строк, начиная со строки №1. 34
Из файла B (обозначенного знаком «+») отображаются 8 строк, также начиная со строки №1. 34

Текст после закрывающей пары "@@" опять-таки призван прояснить контекст: Git пытается отобразить имя метода или другую контекстную информацию о том, откуда в файле был взят этот фрагмент. Однако это сильно зависит от языка программирования и работает не во всех сценариях.

Изменения

Каждая измененная строка начинается с символа "+" или "-". Как объяснялось, эти символы помогают понять, как именно выглядят версии A и B: строка со знаком «-» начинается с A, а строка со знаком «+» — с B.
В большинстве случаев Git выбирает A и B таким образом, что вы можете считать A/- «старым» контентом, а B/+ — «новым».

Давайте посмотрим на наш пример:

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

Различия в башне

Если вы используете клиент Tower Git, его встроенное средство просмотра различий поможет вам быстро понять изменения. Вы можете не только увидеть, какие строки были изменены в файле, но — благодаря встроенной функции выделения — что точно было изменено:

Проверка локальных изменений

Ранее в этой книге мы часто использовали команду "git status", чтобы увидеть, какие файлы в настоящее время изменены в нашей рабочей копии. Чтобы понять, как они были изменены в деталях, мы можем спросить "git diff":

Без дополнительных опций "git diff" покажет нам все текущие локальные изменения в нашей рабочей копии, которые не были подготовлены.
Если вы хотите просмотреть только те изменения, которые уже были добавлены в тестовую область, выберите команду "git diff --staged".

Проверка зафиксированных изменений

Вы уже знаете, что команда "git log" предоставляет обзор последних коммитов. Если вы хотите видеть больше, чем стандартные метаданные (хэш, автор, дата, сообщение), вы можете добавить флаг "-p", чтобы получить подробные "заплатки" для каждой фиксации.

Сравнение ветвей и ревизий

Наконец, вам может понадобиться узнать, чем одна ветвь (или даже конкретная версия) отличается от другой. Посмотрим все изменения из ветки "contact-form", которых у нас пока нет в "master":

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

Получите нашу популярную памятку по Git бесплатно!

Самые важные команды вы найдете на лицевой стороне, а полезные советы — на обратной. Более 100 000 разработчиков скачали его, чтобы сделать Git немного проще.

О нас

Как создатели Tower, лучшего клиента Git для Mac и Windows, мы помогаем более чем 100 000 пользователей в таких компаниях, как Apple, Google, Amazon, Twitter и Ebay, получить максимальную отдачу от Git.

Как и в случае с Tower, наша миссия с этой платформой – помочь людям стать лучшими профессионалами.

Вот почему мы бесплатно предоставляем наши руководства, видеоролики и памятки (об управлении версиями в Git и многих других темах).

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

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

Найти, какой файл был изменен при фиксации

Чтобы узнать, какие файлы были изменены в данной фиксации, используйте команду git log --raw. Это самый быстрый и простой способ узнать, на какие файлы влияет фиксация. Команда git log в целом используется недостаточно, в основном из-за того, что у нее очень много параметров форматирования, и многие пользователи перегружены слишком большим количеством вариантов и, в некоторых случаях, нечеткой документацией.

Однако механизм журналов в Git на удивление гибкий, а параметр --raw предоставляет журнал коммитов в вашей текущей ветке, а также список всех файлов, в которые были внесены изменения.

Вот вывод стандартного журнала git:

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

Вот вывод git log --raw :

Это говорит вам, какой именно файл был добавлен в фиксацию и как файл был изменен (A для добавления, M для изменения, R для переименования и D для удаления).

Получить, что изменилось

Команда git whatchanged — это устаревшая команда, предшествующая функции журнала. Его документация говорит, что вы не должны использовать его в пользу git log --raw и подразумевает, что он по существу устарел. Тем не менее, я по-прежнему нахожу это полезным ярлыком (в основном) для того же вывода (хотя коммиты слияния исключены), и я предполагаю создать для него псевдоним, если он когда-либо будет удален. Если вам не нужно объединять коммиты в своем журнале (а вы, вероятно, этого не делаете, если хотите увидеть только измененные файлы), попробуйте git whatchanged в качестве простой мнемоники.

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

Вы можете не только увидеть, какие файлы были изменены, но и заставить git log отображать именно то, что изменилось в файлах. Ваш журнал Git может создать встроенный diff, построчное отображение всех изменений для каждого файла с опцией --patch:

В этом примере строка из одного слова "world" была удалена из hello.txt и добавлена новая строка "opensource.com".

Эти исправления можно использовать с обычными утилитами Unix, такими как diff и patch, если вам потребуется внести те же изменения вручную в другом месте. Патчи также являются хорошим способом суммировать важные части новой информации, которую вводит конкретный коммит. Это бесценный обзор, когда вы представили ошибку во время спринта. Чтобы быстрее найти причину ошибки, вы можете игнорировать части файла, которые не изменились, и просматривать только новый код.

Простые команды для сложных результатов

Вам не нужно разбираться в ссылках и ветвях и хэшах коммитов, чтобы увидеть, какие файлы были изменены в коммите. Ваш журнал Git был разработан, чтобы сообщать вам об активности Git, и если вы хотите отформатировать его определенным образом или извлечь определенную информацию, часто приходится просматривать множество экранов документации, чтобы собрать правильную команду. К счастью, один из самых распространенных запросов об истории Git доступен только с одним или двумя параметрами: --raw и --patch . И если вы не можете вспомнить --raw , просто подумайте: «Чёрт, что изменилось?» и введите git whatchanged .

3 причины, по которым я использую команду Git cherry-pick

Выбор вишен решает множество проблем в репозиториях Git. Вот три способа исправить свои ошибки с помощью git cherry-pick.

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

Отменяйте изменения в репозитории с помощью простых и элегантных команд Git.

В этой статье мы рассмотрим 3 лучших способа вывести список всех измененных файлов после коммита git. Если вы разработчик или программист, работаете над проектом и регулярно отправляете свои коды в репозиторий Git, возможно, вы сталкивались с ситуацией, когда вам нужно проверять все файлы, которые были изменены или модифицированы после Git Commit. Очень часто разработчики ищут изменения, сделанные во время различных коммитов, прежде чем отправить свой код в репозиторий Git.

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

Что такое Git Commit ID

Это уникальный хэш SHA-1, который создается после каждой фиксации, сделанной пользователем Git. В основном он содержит информацию обо всех изменениях, внесенных в этот конкретный коммит.

Лучшие способы вывести список всех измененных файлов после Git Commit

Способ 1: использование журнала git

Один из самых популярных способов проверки всех идентификаторов фиксации и изменений, сделанных с помощью этого идентификатора фиксации, – использование команды git log. Если вы просто запустите команду git log, вы получите список всех коммитов, сделанных до сих пор. Но если вы используете команду git log -p, вы увидите все коммиты вместе с изменениями, сделанными в каждом коммите. Таким образом, вывод будет довольно длинным в этом методе. Подробнее на справочной странице git log.

Обратите внимание, что здесь я запускаю все команды из оболочки gcloud. Возможно, вы используете какую-либо машину на базе Linux для фиксации своего кода. Вы можете использовать любую платформу с установленной утилитой git. Это действительно не имеет значения.

Способ 2. Использование git show

Еще одна очень полезная команда, которую вы можете использовать, — это команда git show. Используя этот метод, вы можете проверить все изменения, внесенные в определенный идентификатор фиксации. Синтаксис для использования команды: git show. Вы можете получить все идентификаторы фиксации из команды git log. Здесь мы проверяем список изменений для идентификатора фиксации da475798411a3e2769219b4a7655b6821c4d1901 с помощью команды git show, как показано ниже.

Способ 3. Использование git diff

Еще одна важная команда, которую вы можете использовать, — это команда git diff для проверки списка файлов, измененных между двумя идентификаторами фиксации. Синтаксис этой команды: git diff --name-only .. . Здесь вам нужно указать начальный идентификатор фиксации и конечный идентификатор фиксации, чтобы узнать все изменения, сделанные между этими двумя идентификаторами фиксации.Например, мы случайно выбрали идентификатор начальной фиксации как 30b1d202d7e2727085d7dc8349ce8b0f67686f2d и идентификатор конечной фиксации как da475798411a3e2769219b4a7655b6821c4d1901 из команды git log, как показано ниже. Из вывода видно, что между этими двумя фиксациями изменены файлы cloudbuild.yaml и newfile.

Читайте также: