В большинстве случаев взаимодействие с системой контроля версий Git осуществляется локально. Однако периодически возникает необходимость синхронизации с удаленным репозиторием, чтобы обновить данные в своем локальном хранилище. Для этого в Git предусмотрены два ключевых инструмента: команды git fetch
и git pull
.
Удаленный репозиторий — это хранилище, расположенное в сети, обычно на специализированных платформах вроде GitHub, GitLab или Bitbucket. Такие сервисы позволяют разработчикам совместно работать над проектами, внося изменения и синхронизируя код между локальными и удалёнными версиями.
Обе рассматриваемые команды предназначены для загрузки обновлений из удалённого репозитория, но работают они по-разному. В данном материале мы разберем их практическое применение и выявим основные различия между ними.
В связи с тем, что в данной статье будет рассмотрена практическая часть, то для ее выполнения нам понадобится следующее:
git fetch
— это команда, предназначенная для загрузки актуальных данных из удаленного репозитория в локальное хранилище без изменения файлов в рабочей директории. Вместо этого обновляются так называемые удаленные отслеживаемые ветки, которые отражают состояние удаленного репозитория на момент выполнения команды.
git fetch <адрес удаленного репозитория>
Полезные параметры:
git fetch --all
— загружает обновления сразу из всех удаленных репозиториев, связанных с локальным хранилищем.git fetch --dry-run
— выполняет проверку изменений перед загрузкой, не внося фактических изменений.git fetch --force
— принудительно обновляет данные в локальном репозитории, перезаписывая возможные конфликты.git fetch --tags
— скачивает все теги из удаленного репозитория.git fetch --prune
— удаляет ссылки на ветки, которые были удалены в удаленном репозитории.В отличие от git fetch
, команда git pull
не только загружает последние изменения из удаленного репозитория, но и автоматически сливает их с текущей локальной веткой. По сути, выполнение git pull
включает две операции:
git fetch
— загрузка новых данных.git merge
— объединение загруженных изменений с локальной веткой.git pull
Полезные параметры:
git pull [удаленный_репозиторий] [ветка]
— загружает изменения только из указанного репозитория и ветки. Например, git pull origin main
обновит локальную ветку main
из удаленного репозитория origin
.git pull --rebase
— вместо стандартного слияния (merge) применяет изменения сверху локальных коммитов, позволяя избежать лишних коммитов слияния.Чтобы лучше понять различия между этими командами, рассмотрим их основные характеристики в виде таблицы:
Критерий |
git fetch |
git pull |
Действие |
Только загружает изменения |
Загружает и сливает изменения |
Влияние на локальный репозиторий |
Не изменяет файлы или ветки |
Модифицирует текущую ветку и файлы |
Безопасность |
Безопасна, так как не вызывает конфликты |
Может вызвать конфликты при слиянии |
Предварительный просмотр изменений |
Позволяет просматривать и анализировать изменения перед их слиянием |
Автоматически интегрирует изменения без возможности предварительного просмотра |
Гибкость |
Требует ручного слияния |
Процесс слияния происходит автоматически |
На основании данных из таблицы можно сделать вывод, что использовать команды стоит в следующих случаях.
Перед внесением изменений в исходный код. Команда позволяет просматривать, какие коммиты были сделаны в удаленной ветке, и оценивать внесенные изменения.
При работе в команде. Если над проектом работают несколько разработчиков, git fetch
помогает быть в курсе их работы и минимизировать количество потенциальных конфликтов перед объединением изменений.
Для получения новых веток и тегов. Если в удаленный репозиторий была добавлена новая ветка или новый тег, git fetch
скачает их, но не произведет переключение на них автоматически.
Для получения последних актуальных изменений. При командной работе участники проекта периодически вносят изменения. Чтобы получить все последние изменения в локальный репозиторий, необходимо использовать git pull
.
Для быстрого обновления ветки. Если необходимо быстро актуализировать ветку без предварительного анализа, имеет смысл использовать git pull
.
cloud
Рассмотрим использование команд git fetch
и git pull
на практике.
При необходимости пройдите аутентификацию при помощи мобильного приложения.
mkdir test-git-fetch-pull && cd test-git-fetch-pull
git init
echo "Test git fetch and pull commands!" > newfile1.txt
git add newfile1.txt
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"
В нашем случае команда будет следующей:
git remote add origin https://github.com/AlexFromMoscow6/test-git-fetch-pull.git
git push -u origin main
При появлении фразы Username for 'https://github.com'
вводим свой логин, при появлении фразы Password for 'https://<логин>@github.com'
вводим ранее сгенерированный токен.
Возвращаемся в веб-интерфейс GitHub и проверяем наличие файла в репозитории:
Добавляем новую строку в конец файла:
git fetch origin
Как можно увидеть, git загрузил изменения из удаленного репозитория, но локальная ветка main
и файл остались без изменений. Однако, внесенные изменения можно увидеть в удаленной ветке:
git log origin/main
Если необходимо проверить, какие именно изменения были внесены в репозиторий при выполнении команды git fetch, можно воспользоваться командой:
git diff main origin/main
git pull
:git pull origin main
И проверим содержимое файла:
Теперь ранее внесенные изменения в файл, выполненные в интерфейсе GitHub, применены к локальной копии репозитория.
При использовании git pull
можно столкнуться с конфликтами. В терминологии Git под конфликтом понимают ситуацию, когда система не может автоматически объединить изменения из двух разных источников — из локального и удаленного репозиториев.
Чтобы научиться решать конфликты, разберем их на практике. Сымитируем следующую ситуацию: предположим, у нас есть репозиторий, внутри которого хранится файл future-file1.txt
. Над проектом работают два разработчика (Разработчик1 и Разработчик2), которые используют одну ветку (main
).
Прежде чем приступить к практике, необходимо создать новый репозиторий в GitHub, как это было сделано в предыдущей главе. Далее:
mkdir git-conflicts && cd git-conflicts
git init
touch future-file1.txt
И записываем в файл строку First message
:
echo "First message" > future-file1.txt
git add future-file1.txt
git commit -m "Initial commit"
git-conflicts.git
— это название репозитория в GitHub):git remote add origin https://github.com/AlexFromMoscow6/git-conflicts.git
main
:git push -u origin main
Для отправки изменений необходимо будет ввести имя пользователя и токен.
Далее сымитируем ситуацию от имени уже второго разработчика (Разработчик2). Для этого скачиваем репозиторий проекта на локальную машину или создаем новую директорию на сервере и в ней выполняем команду:
git clone https://github.com/AlexFromMoscow6/git-conflicts.git
На текущий момент оба разработчика обладают актуальной копией репозитория.
Далее возвращаемся в локальный репозиторий, который инициировал первый разработчик.
future-file1.txt:
echo "Second message" > future-file1.txt
git add future-file1.txt
git commit -m "Second commit"
git push origin main
Теперь ситуация следующая — у первого разработчика актуальная версия репозитория, в то время как у второго разработчика отсутствуют внесенные изменения. Переключаемся на директорию второго разработчика и переходим в ранее скачанную папку с проектом.
echo "Third message" > future-file1.txt
git add future-file1.txt
git commit -m "Third commit"
git pull origin main
Как можно увидеть, в git произошел конфликт:
При просмотре файла в нем будет отображаться конфликтный блок:
Чтобы разрешить конфликт, необходимо удалить строки начинающиеся с символов <<<<<<<
и >>>>>>>
. Далее можно решить, стоит ли оставлять только локальные изменения или стоит оставить старые и добавить новые.
Second message
) и второго разработчика (Third message
):git add future-file1.txt
git commit -m "Resolved conflict"
git push origin main
Для отправки изменений необходимо будет ввести имя пользователя и токен.
Возвращаемся в интерфейс GitHub и смотрим результат:
В итоге мы получили файл, в котором оставили старые изменения, внесенные первым разработчиком, а также добавили новые изменения, внесенные вторым разработчиком.
Выгодные тарифы на облако в Timeweb Cloud
Команды git fetch
и git pull
предназначены для загрузки последних изменений из удаленного репозитория в локальный, однако они делают это по-разному.
Использование git fetch
позволяет безопасно получать обновления, анализировать внесенные другими участниками изменения, не затрагивая текущую рабочую копию. Это особенно полезно для предотвращения неожиданных конфликтов, так как никакие изменения не применяются автоматически.
В свою очередь, git pull
выполняет не только загрузку данных, но и их немедленное слияние с локальным репозиторием. Этот процесс требует осторожности, поскольку при наличии конфликтов их придётся разрешать вручную.
Выбор между этими командами зависит от ваших целей: если вам важно сначала проверить изменения, используйте git fetch
, а если нужно быстро обновить код — применяйте git pull
, но с пониманием возможных последствий.