git remotes

git pull

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

Описание

git pull — это комбинация двух операций: git fetch (загрузить изменения с remote) и git merge или git rebase (интегрировать их в текущую ветку). Это наиболее распространённый способ синхронизировать локальную работу с командой.

По умолчанию pull использует стратегию слияния (merge): если локальная и удалённая ветки разошлись, создаётся merge-коммит. Альтернатива — git pull --rebase, которая «перекладывает» ваши коммиты поверх загруженных, сохраняя линейную историю. Многие команды настраивают rebase как поведение по умолчанию.

Если в рабочем каталоге есть незакоммиченные изменения, pull может завершиться ошибкой конфликта. В таком случае сначала закоммитьте или сохраните изменения через git stash, выполните pull, затем восстановите (git stash pop).

Синтаксис

git pull [<options>] [<remote> [<refspec>...]]

Без аргументов git pull использует tracking-remote текущей ветки (обычно origin) и одноимённую удалённую ветку. Можно явно указать remote и ветку: git pull origin main. Параметр refspec позволяет тонко настроить маппинг веток при pull.

Флаги и опции

Флаг Описание
--rebase, -r Вместо merge выполнить rebase локальных коммитов поверх загруженных. Сохраняет линейную историю без merge-коммитов.
--rebase=interactive Выполнить интерактивный rebase (git rebase -i) после fetch. Позволяет редактировать порядок и содержание коммитов перед интеграцией.
--no-rebase Явно использовать merge (отменяет настройку pull.rebase = true из конфига).
--ff-only Разрешить только fast-forward слияние. Если fast-forward невозможен (ветки разошлись), команда завершится с ошибкой — без автоматического merge-коммита.
--no-ff Всегда создавать merge-коммит, даже если возможен fast-forward. Делает историю слияний явной.
--squash Сжать все загружаемые коммиты в один перед слиянием. Коммит нужно сделать явно после.
--autostash Автоматически выполнить git stash перед pull и git stash pop после. Удобно, если есть незакоммиченные изменения.
--prune, -p Передать флаг --prune в fetch: удалить устаревшие tracking-ветки при pull.
--tags Загрузить все теги с remote (передаётся в fetch-часть команды).
--depth=<n> Ограничить загружаемую историю n коммитами. Для shallow-клонов в CI.
--verbose, -v Подробный вывод: показывать каждую загружаемую ссылку и результат слияния.
--quiet, -q Минимальный вывод — только ошибки и предупреждения.

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

Стандартный pull

# Простой pull с merge
git pull

# С явным указанием remote и ветки
git pull origin main

# Только если fast-forward возможен
git pull --ff-only

Pull с rebase (чистая история)

# Один раз: rebase вместо merge
git pull --rebase

# Настроить для конкретного репо
git config pull.rebase true

# Настроить глобально
git config --global pull.rebase true

Pull при наличии незакоммиченных изменений

# Вариант 1: сохранить в stash
git stash
git pull
git stash pop

# Вариант 2: автоматически
git pull --autostash

# Вариант 3: закоммитить перед pull
git add -A && git commit -m "wip: save work"
git pull --rebase

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

# После конфликта — посмотреть статус
git status

# Открыть конфликтный файл, исправить вручную
# Затем отметить как решённый
git add conflicted-file.txt

# Завершить merge
git merge --continue
# или завершить rebase
git rebase --continue

Pull конкретной ветки в текущую

# Влить удалённую ветку feature в текущую
git pull origin feature/payment

# То же самое вручную (более явно)
git fetch origin feature/payment
git merge origin/feature/payment

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

# Обновиться и удалить устаревшие tracking-ветки
git pull --prune

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

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

Rebase vs Merge: Используйте git pull --rebase для поддержания линейной истории в feature-ветках. Для main/develop при командной работе иногда предпочтительнее явный merge-коммит — он документирует момент интеграции. Договоритесь о стратегии в команде и зафиксируйте в .gitconfig.
Используйте --ff-only на защищённых ветках: Настройте git config branch.main.mergeoptions "--ff-only" для main-ветки. Это предотвратит случайные merge-коммиты — если история разошлась, pull упадёт с явной ошибкой, и вы поймёте, что нужно выровнять ветки.
git pull в середине работы: Никогда не выполняйте git pull в момент, когда у вас есть несохранённые изменения в середине сложной задачи. Git может автоматически создать merge-коммит, который перемешает вашу незавершённую работу с чужим кодом. Сначала закоммитьте или используйте --autostash.
Конфликты при rebase: При git pull --rebase конфликты решаются по одному для каждого вашего коммита. Если у вас 5 коммитов и конфликт в каждом — придётся решить 5 конфликтов. В таком случае может быть проще прервать (git rebase --abort) и использовать обычный merge.