<div><img src="https://top-fwz1.mail.ru/counter?id=3548135;js=na" style="position:absolute;left:-9999px;" alt="Top.Mail.Ru" /></div>
Публичное облако на базе VMware с управлением через vCloud Director

Git Fetch и Git Pull: чем отличаются и как работают команды

Александр Бархатов
Александр Бархатов
Технический писатель
11 февраля 2025 г.
69
11 минут чтения
Средний рейтинг статьи: 5

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

Удаленный репозиторий — это хранилище, расположенное в сети, обычно на специализированных платформах вроде GitHub, GitLab или Bitbucket. Такие сервисы позволяют разработчикам совместно работать над проектами, внося изменения и синхронизируя код между локальными и удалёнными версиями.

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

Предварительные требования

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

  • Сервер, виртуальная машина или компьютер с любой операционной системой, куда можно установить систему контроля версий Git. 
  • Заранее установленный клиент Git
  • Учетная запись на сайте Github.

Команда git fetch

Что делает git fetch?

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

Как работает git fetch?

  1. Устанавливает соединение с удаленным репозиторием.
  2. Загружает новые коммиты, файлы, ветки и теги.
  3. Данные добавляются в локальный репозиторий, но не сливаются с текущей рабочей веткой.

Базовый синтаксис git fetch

git fetch <адрес удаленного репозитория>

Полезные параметры:

  • git fetch --all — загружает обновления сразу из всех удаленных репозиториев, связанных с локальным хранилищем.
  • git fetch --dry-run — выполняет проверку изменений перед загрузкой, не внося фактических изменений.
  • git fetch --force — принудительно обновляет данные в локальном репозитории, перезаписывая возможные конфликты.
  • git fetch --tags — скачивает все теги из удаленного репозитория.
  • git fetch --prune — удаляет ссылки на ветки, которые были удалены в удаленном репозитории.

Команда git pull

Что делает git pull?

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

  1. git fetch — загрузка новых данных.
  2. git merge — объединение загруженных изменений с локальной веткой.

Как работает git pull?

  1. Устанавливает соединение с удаленным репозиторием.
  2. Загружает актуальные данные, включая коммиты, файлы, теги и ветки.
  3. Загруженные изменения объединяются с текущей локальной веткой.

Базовый синтаксис git pull

git pull

Полезные параметры:

  • git pull [удаленный_репозиторий] [ветка] — загружает изменения только из указанного репозитория и ветки. Например, git pull origin main обновит локальную ветку main из удаленного репозитория origin.
  • git pull --rebase — вместо стандартного слияния (merge) применяет изменения сверху локальных коммитов, позволяя избежать лишних коммитов слияния.

Сравнение git fetch и git pull

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

Критерий

git fetch

git pull

Действие

Только загружает изменения

Загружает и сливает изменения

Влияние на локальный репозиторий

Не изменяет файлы или ветки

Модифицирует текущую ветку и файлы

Безопасность

Безопасна, так как не вызывает конфликты

Может вызвать конфликты при слиянии

Предварительный просмотр изменений 

Позволяет просматривать и анализировать изменения перед их слиянием

Автоматически интегрирует изменения без возможности предварительного просмотра

Гибкость

Требует ручного слияния

Процесс слияния происходит автоматически

Когда использовать Git Fetch, а когда Git Pull

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

Когда использовать git fetch?

  1. Перед внесением изменений в исходный код. Команда позволяет просматривать, какие коммиты были сделаны в удаленной ветке, и оценивать внесенные изменения.

  2. При работе в команде. Если над проектом работают несколько разработчиков, git fetch помогает быть в курсе их работы и минимизировать количество потенциальных конфликтов перед объединением изменений.

  3. Для получения новых веток и тегов. Если в удаленный репозиторий была добавлена новая ветка или новый тег, git fetch скачает их, но не произведет переключение на них автоматически.

Когда использовать git pull?

  1. Для получения последних актуальных изменений. При командной работе участники проекта периодически вносят изменения. Чтобы получить все последние изменения в локальный репозиторий, необходимо использовать git pull.

  2. Для быстрого обновления ветки. Если необходимо быстро актуализировать ветку без предварительного анализа, имеет смысл использовать git pull.

cloud

Использование git fetch и git pull на практике

Рассмотрим использование команд git fetch и git pull на практике.

Создание репозитория в GitHub

  1. Для начала проходим авторизацию на Github. Если аккаунта у вас нет, можно зарегистрировать новый
  2. Далее нам необходимо создать новый репозиторий. Для этого нажимаем на кнопку New:

Image25

  1. Задаем имя для репозитория, а также делаем его публичным (выбираем пункт Public) и нажимаем на кнопку Create repository:

Image8

  1. Далее нам необходимо создать токен, чтобы отправлять изменения в удаленный репозиторий. Для этого в интерфейсе GitHub справа сверху нажимаем на аватар и в открывшемся меню выбираем пункт Settings.
  2. Переходим в раздел Developer settings слева внизу:

Image4

  1. В меню слева раскрываем раздел Personal access tokens и переходим в раздел Tokens (classic):

Image10

  1. Для создания нового токена нажимаем на кнопку Generate new token, далее Generate new token (classic):

Image15

При необходимости пройдите аутентификацию при помощи мобильного приложения.

  1. Задаем имя для токена, его срок действия и в качестве прав выбираем права категории repo:

Image12

  1. Для создания токена нажимаем на кнопку Generate token.
  2. Копируем и сохраняем появившейся токен, так как больше он отображаться не будет.

Создание локального репозитория

  1. Переходим на сервер, где установлен Git. Создаем новый каталог, где будут храниться файлы и переходим в него:
mkdir test-git-fetch-pull && cd test-git-fetch-pull
  1. Инициализируем новый репозиторий git:
git init
  1. Создаем новый файл и добавим в него фразу "Test git fetch and pull commands!":
echo "Test git fetch and pull commands!" > newfile1.txt
  1. Добавляем созданный файл в индекс:
git add newfile1.txt
  1. Создаем коммит:
git commit -m "Initial commit"

При появлении сообщения Author identity unknown *** Please tell me who you are необходимо предоставить свое имя и адрес электронной почты:

git config --global user.email "world@gmail.com"
git config --global user.name "Alex"

Далее необходимо выполнить команду для создания коммита еще раз:

git commit -m "Initial commit"
  1. Подключаем ранее созданный удаленный репозиторий в GitHub. Команду для подключения можно найти на главной странице репозитория сразу после его создания в GitHub:

Image6

В нашем случае команда будет следующей:

git remote add origin https://github.com/AlexFromMoscow6/test-git-fetch-pull.git
  1. Отправляем изменения в удаленный репозиторий:
git push -u origin main

При появлении фразы Username for 'https://github.com' вводим свой логин, при появлении фразы Password for 'https://<логин>@github.com' вводим ранее сгенерированный токен.

Возвращаемся в веб-интерфейс GitHub и проверяем наличие файла в репозитории:

Image21

Работа с изменениями

  1. Теперь сымитируем изменения в удаленном репозитории. Для этого открываем файл на редактирование в интерфейсе GitHub:

Image20

Добавляем новую строку в конец файла:

Image19

  1. Делаем коммит, нажав на кнопку Commit changes справа.
  2. Возвращаемся на сервер в локальный репозиторий и выполняем команду:
git fetch origin

Image9

  1. Теперь выведем содержимое файла: 

Image3

Как можно увидеть, git загрузил изменения из удаленного репозитория, но локальная ветка main и файл остались без изменений. Однако, внесенные изменения можно увидеть в удаленной ветке:

git log origin/main

Image17

Если необходимо проверить, какие именно изменения были внесены в репозиторий при выполнении команды git fetch, можно воспользоваться командой:

git diff main origin/main

Image23

  1. Теперь выполним команду git pull:
git pull origin main

Image13

И проверим содержимое файла:

Image14

Теперь ранее внесенные изменения в файл, выполненные в интерфейсе GitHub, применены к локальной копии репозитория.

Решение конфликтов при использовании команды git pull

При использовании git pull можно столкнуться с конфликтами. В терминологии Git под конфликтом понимают ситуацию, когда система не может автоматически объединить изменения из двух разных источников — из локального и удаленного репозиториев.

Чтобы научиться решать конфликты, разберем их на практике. Сымитируем следующую ситуацию: предположим, у нас есть репозиторий, внутри которого хранится файл future-file1.txt. Над проектом работают два разработчика (Разработчик1 и Разработчик2), которые используют одну ветку (main).

Подготовка репозитория

Прежде чем приступить к практике, необходимо создать новый репозиторий в GitHub, как это было сделано в предыдущей главе. Далее:

  1. Создаем новую директорию на сервере и переходим в нее:
mkdir git-conflicts && cd git-conflicts
  1. Инициализируем репозиторий git:
git init
  1. Создаем новый файл:
touch future-file1.txt

И записываем в файл строку First message:

echo "First message" > future-file1.txt
  1. Добавляем созданный файл в индекс git:
git add future-file1.txt
  1. Далее делаем коммит:
git commit -m "Initial commit"
  1. Подключаем ранее созданный в GitHub репозиторий (где git-conflicts.git — это название репозитория в GitHub):
git remote add origin https://github.com/AlexFromMoscow6/git-conflicts.git
  1. Отправляем изменения в удаленный репозиторий в ветку main:
git push -u origin main

Для отправки изменений необходимо будет ввести имя пользователя и токен.

Внесение изменений со стороны второго разработчика

Далее сымитируем ситуацию от имени уже второго разработчика (Разработчик2). Для этого скачиваем репозиторий проекта на локальную машину или создаем новую директорию на сервере и в ней выполняем команду:

git clone https://github.com/AlexFromMoscow6/git-conflicts.git

На текущий момент оба разработчика обладают актуальной копией репозитория.

Внесение изменений со стороны первого разработчика

Далее возвращаемся в локальный репозиторий, который инициировал первый разработчик.

  1. Добавляем новое сообщение путем его перезаписи future-file1.txt:
echo "Second message" > future-file1.txt
  1. Добавляем файл в индекс:
git add future-file1.txt
  1. Делаем коммит:
git commit -m "Second commit"
  1. Отправляем изменения в удаленный репозиторий:
git push origin main

Конфликт

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

  1. Перезаписываем файл путем добавки нового сообщения:
echo "Third  message" > future-file1.txt
  1. Добавляем файл в индекс git:
git add future-file1.txt
  1. Делаем коммит:
git commit -m "Third commit"
  1. Теперь попытаемся получить актуальные данные из удаленного изменения:
git pull origin main

Как можно увидеть, в git произошел конфликт:

Image11

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

Image22

Разрешение конфликта 

Чтобы разрешить конфликт, необходимо удалить строки начинающиеся с символов <<<<<<< и >>>>>>>. Далее можно решить, стоит ли оставлять только локальные изменения или стоит оставить старые и добавить новые.

  1. В качестве примера оставим изменения от первого разработчика (сообщение Second message) и второго разработчика (Third message):

Image18

  1. После того как файл был отредактирован, добавляем его в индекс:
git add future-file1.txt
  1. Делаем коммит:
git commit -m "Resolved conflict"
  1. Отправляем изменения в удаленный репозиторий:
git push origin main

Для отправки изменений необходимо будет ввести имя пользователя и токен.

Возвращаемся в интерфейс GitHub и смотрим результат:

Image7

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

Выгодные тарифы на облако в Timeweb Cloud

Заключение

Команды git fetch и git pull предназначены для загрузки последних изменений из удаленного репозитория в локальный, однако они делают это по-разному.

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

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

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

Хотите внести свой вклад?
Участвуйте в нашей контент-программе за
вознаграждение или запросите нужную вам инструкцию
img-server
11 февраля 2025 г.
69
11 минут чтения
Средний рейтинг статьи: 5
Пока нет комментариев