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

Введение

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

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

Получение изменений из удаленного репозитория с помощью git fetch

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

Сначала имитируем наличие удаленного репозитория. Создадим пустой (bare) репозиторий и добавим его в качестве удаленного для нашего существующего репозитория my-time-machine.

cd ~/project
mkdir remote-repo.git
cd remote-repo.git
git init --bare

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

Теперь вернемся в наш репозиторий my-time-machine и добавим этот пустой репозиторий в качестве удаленного.

cd ~/project/my-time-machine
git remote add origin ~/project/remote-repo.git

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

git remote -v

Вы должны увидеть вывод, похожий на следующий, показывающий URL-адреса для получения и отправки изменений для удаленного репозитория origin:

origin /home/labex/project/remote-repo.git (fetch)
origin /home/labex/project/remote-repo.git (push)

Теперь имитируем изменение в удаленном репозитории. Поскольку это пустой репозиторий, мы не можем напрямую делать коммиты в нем. Вместо этого мы имитируем изменение, создав новый файл в директории пустого репозитория.

cd ~/project/remote-repo.git
echo "This is a remote change" > remote_file.txt

Теперь вернемся в наш репозиторий my-time-machine.

cd ~/project/my-time-machine

На данном этапе ваш локальный репозиторий не знает о файле remote_file.txt, который был добавлен в имитируемый удаленный репозиторий. Именно здесь приходит на помощь команда git fetch.

Запустите команду git fetch:

git fetch origin

Вы, возможно, не увидите большого количества вывода, или же увидите что-то, указывающее на то, что были получены новые объекты.

Команда git fetch origin подключилась к удаленному репозиторию origin и загрузила все новые коммиты и объекты, которых еще нет в вашем локальном репозитории. Однако она не объединила эти изменения с текущей веткой (master). Изменения теперь доступны в вашем локальном репозитории, но они хранятся в специальной ветке, которая отслеживает удаленный репозиторий, обычно называемой origin/master.

Вот основное различие между git fetch и git pull. git pull по сути представляет собой последовательное выполнение git fetch и объединения изменений. Используя сначала git fetch, вы можете увидеть, какие изменения доступны на удаленном репозитории, прежде чем решить, интегрировать ли их в свою работу. Это дает вам больше контроля и помогает избежать непредвиденных конфликтов.

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

Выполнение команды git log HEAD..@{u}

На предыдущем этапе мы использовали команду git fetch для загрузки изменений из удаленного репозитория. Теперь посмотрим, как можно просмотреть коммиты, которые есть на удаленном репозитории, но еще не в нашей локальной ветке. Именно здесь команда git log HEAD..@{u} очень полезна.

Убедитесь, что вы все еще находитесь в директории ~/project/my-time-machine.

cd ~/project/my-time-machine

Теперь выполните следующую команду:

git log HEAD..@{u}

Вы, возможно, увидите вывод, похожий на следующий:

commit abcdef1234567890abcdef1234567890abcdef (origin/master)
Author: Simulated User <simulated.user@example.com>
Date:   Mon Aug 7 10:05:00 2023 +0000

    Simulated remote commit

Разберем эту команду на составляющие:

• git log: Это команда для просмотра истории коммитов.
• HEAD: Эта ссылка указывает на коммит, на который в данный момент указывает ваша текущая ветка.
• @{u}: Это сокращенное обозначение для ветки-родителя (upstream branch). В нашем случае, так как мы загрузили изменения из origin, и наша локальная ветка master отслеживает origin/master, @{u} ссылается на origin/master.
• HEAD..@{u}: Это нотация диапазона в Git. Она означает "покажи мне коммиты, которые достижимы из @{u}, но недостижимы из HEAD". Проще говоря, она показывает коммиты, которые есть на удаленной отслеживаемой ветке (origin/master), но которых еще нет на вашей текущей локальной ветке (master).

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

Возможно, вы задаетесь вопросом: "Как Git узнал о имитированном удаленном коммите?" Когда мы выполнили команду git fetch origin на предыдущем этапе, Git загрузил информацию о коммитах в репозитории origin, включая коммит, в котором был добавлен файл remote_file.txt. Эта информация хранится в отслеживающей ветке origin/master в вашем локальном репозитории. Затем команда git log HEAD..@{u} сравнивает вашу локальную ветку master (HEAD) с этой отслеживающей веткой origin/master (@{u}), чтобы показать разницу.

Нажмите q, чтобы выйти из режима просмотра лога, если он отображается в полноэкранном режиме.

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

Тестирование синхронизированных удаленных репозиториев

На предыдущих этапах мы загрузили изменения из имитированного удаленного репозитория и узнали, как просмотреть коммиты, которые есть на удаленном репозитории, но еще не в нашей локальной ветке, используя команду git log HEAD..@{u}. Теперь посмотрим, что произойдет, когда наша локальная ветка будет синхронизирована с удаленной отслеживаемой веткой.

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

Убедитесь, что вы находитесь в директории ~/project/my-time-machine.

cd ~/project/my-time-machine

Теперь имитируем объединение, сбросив нашу локальную ветку master на тот же коммит, что и ветка origin/master. Примечание: В реальной ситуации вы обычно используете git merge origin/master или git pull origin master для интеграции изменений. Здесь мы используем git reset --hard исключительно в демонстрационных целях, чтобы быстро синхронизировать нашу локальную ветку с удаленной отслеживаемой веткой для теста.

git reset --hard origin/master

Вы должны увидеть вывод, указывающий на то, что ваша ветка была обновлена и рабочее дерево чисто.

HEAD is now at abcdef1 Simulated remote commit

Теперь, когда наша локальная ветка master синхронизирована с origin/master, запустим команду git log HEAD..@{u} еще раз.

git log HEAD..@{u}

На этот раз вы не должны увидеть никакого вывода.

Почему нет вывода? Потому что HEAD (наша локальная ветка master) и @{u} (отслеживающая ветка origin/master) теперь указывают на один и тот же коммит. Диапазон HEAD..@{u} пуст, так как нет коммитов, достижимых из @{u}, которые не были бы достижимы из HEAD.

Это ожидаемое поведение, когда ваша локальная ветка полностью синхронизирована с ее удаленной отслеживающей веткой. Команда git log HEAD..@{u} - это быстрый способ проверить, есть ли какие-либо входящие изменения из удаленного репозитория, которые вы еще не интегрировали. Если команда не выводит ничего, это означает, что ваша локальная ветка синхронизирована с удаленной отслеживаемой веткой.

Понимание того, как проверять наличие входящих изменений и как интерпретировать вывод команды git log HEAD..@{u}, является важной частью совместной работы с другими разработчиками и поддержания синхронизации между локальным и удаленным репозиториями.

Резюме

В этом практическом занятии (лабораторной работе) мы научились проверять, есть ли новые коммиты в удаленном репозитории Git. Мы начали с понимания назначения команды git fetch, которая загружает изменения из удаленного репозитория без их объединения. Мы имитировали удаленный репозиторий, создав голый (bare) Git-репозиторий и добавив его в качестве удаленного репозитория с именем origin в наш локальный репозиторий my-time-machine. Мы проверили настройку удаленного репозитория с помощью команды git remote -v.

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