git remotes

git fetch

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

Описание

git fetch загружает объекты и ссылки (коммиты, ветки, теги) с удалённого репозитория в локальный, но не изменяет рабочие файлы и не трогает текущую ветку. Это «безопасная» операция: вы получаете актуальное состояние сервера и можете изучить изменения, прежде чем их интегрировать.

После выполнения git fetch origin удалённые ветки становятся доступны как origin/main, origin/feature-x и т.д. Вы можете сравнить их с локальными ветками командами git log, git diff и принять осознанное решение о слиянии или перебазировании.

Ключевое отличие от git pull: fetch только обновляет tracking-ветки, pull дополнительно выполняет merge или rebase в вашу текущую ветку. Опытные разработчики предпочитают fetch + явное слияние — это даёт больший контроль над процессом интеграции изменений.

Синтаксис

git fetch [<options>] [<remote>] git fetch [<options>] <remote> [<refspec>...] git fetch [<options>] --all

Без аргументов git fetch обращается к remote по умолчанию (обычно origin) и загружает все ветки. Можно указать конкретный remote и даже конкретную ветку или тег. refspec — это спецификация вида refs/heads/main:refs/remotes/origin/main, задающая маппинг удалённых ссылок в локальные.

Флаги и опции

Флаг Описание
--all Загрузить данные от всех настроенных remotes одновременно.
--prune, -p Удалить локальные tracking-ветки, которых больше нет на удалённом репозитории. Аналог git remote prune.
--tags, -t Загрузить все теги с remote. По умолчанию Git загружает теги, достижимые из загруженных коммитов; этот флаг форсирует загрузку всех тегов.
--no-tags Не загружать теги. Полезно, если вы хотите только ветки без тегов.
--depth=<n> Ограничить историю n коммитами от вершины каждой ветки. Используется для создания shallow-клонов или углубления существующего.
--unshallow Преобразовать shallow-клон в полный, загрузив всю историю.
--dry-run Показать, что будет сделано, без фактической загрузки данных.
--verbose, -v Подробный вывод: показывать каждую загружаемую ссылку.
--quiet, -q Минимальный вывод — только ошибки.
--force, -f Принудительно обновить локальные ссылки, даже если это не fast-forward. Используйте с осторожностью.
--update-head-ok Разрешить обновление текущей ветки (HEAD). По умолчанию это запрещено, так как может вызвать конфликты.
-j, --jobs=<n> Использовать n параллельных потоков при fetch нескольких remotes или submodules.

Паттерны использования

Базовый fetch и просмотр изменений

# Загрузить обновления
git fetch origin

# Посмотреть, что появилось
git log HEAD..origin/main --oneline

# Сравнить файлы
git diff HEAD origin/main

Fetch конкретной ветки

# Загрузить только одну ветку
git fetch origin feature/new-api

# Создать локальную ветку из неё
git checkout -b feature/new-api origin/feature/new-api

# Или короче (Git >= 2.23)
git switch -c feature/new-api origin/feature/new-api

Синхронизация с upstream (форк)

# Загрузить изменения из оригинального репо
git fetch upstream

# Посмотреть, что нового в main
git log upstream/main --oneline -10

# Влить в свою ветку
git rebase upstream/main

Fetch с очисткой устаревших веток

# Загрузить и удалить устаревшие tracking-ветки
git fetch --prune

# Или настроить это поведение глобально
git config --global fetch.prune true

# Теперь каждый git fetch будет pruning

Fetch всех remotes

# Обновить все remotes разом
git fetch --all --prune

# Посмотреть состояние всех веток
git branch -vv

# Ветки покажут ahead/behind относительно remote

Fetch тега или PR (GitHub)

# Загрузить конкретный тег
git fetch origin v2.1.0

# Загрузить Pull Request по номеру (GitHub)
git fetch origin pull/42/head:pr-42
git checkout pr-42

Советы и подводные камни

Fetch перед pull: Привычка делать git fetch перед git pull позволяет сначала увидеть, что изменилось на сервере (git log HEAD..origin/main), и только потом принимать решение об интеграции. Это особенно важно при работе в команде.
git branch -vv: После fetch запустите git branch -vv — это покажет все локальные ветки с их tracking-remote и статусом (сколько коммитов ahead/behind относительно сервера). Отличный способ получить общую картину без переключения веток.
Fetch не меняет рабочий каталог: После git fetch ваши файлы остаются неизменными. Если вы ожидаете увидеть новый код — нужно дополнительно выполнить git merge origin/main или git rebase origin/main. Отсутствие автоматического слияния — это функция, а не баг.
Shallow clones: В CI/CD системы часто используют git clone --depth=1 для скорости. Если после этого нужна полная история (например, для git log или git blame), выполните git fetch --unshallow. Это может занять время для больших репозиториев.