# git pull

_Удалённые репозитории · GitLab Knowledge Base_

**TL;DR:** Затаскивает обновления с удалённого репозитория и сразу сливает с
текущей веткой. По сути - `git fetch` + `git merge` (или + `git
rebase` с `--rebase`). Самая запутанная команда для новичков.


`git pull` - компактная обёртка над двумя операциями. По умолчанию
делает `fetch` (скачать обновления) и потом `merge` (слить в текущую
ветку).

## Что лучше - pull или fetch + merge?

Чисто технически `git pull` = `git fetch && git merge FETCH_HEAD`.
Но многие разработчики предпочитают делать эти шаги отдельно:

- `git fetch` - посмотреть, что пришло, не трогая локальную ветку.
- `git log origin/main..main` - проверить разницу.
- `git merge` или `git rebase` - слить осознанно.

Это даёт паузу между «получил данные» и «изменил локальную ветку».
На сложных репозиториях полезно.

## --rebase vs merge

По умолчанию pull делает merge. Альтернатива - rebase:

```bash
git pull --rebase
```

Это значит: затащить удалённые коммиты, потом *переписать* твои
локальные коммиты так, будто ты их сделал поверх свежих удалённых.
История остаётся линейной, без merge-коммитов.

Какой вариант лучше - спор десятилетий. Прагматичное правило:

- **rebase** для своей feature-ветки, пока никому её не показал.
- **merge** для общих веток (main, master).
- Установить дефолт можно конфигом: `git config --global pull.rebase true`.

Без явной настройки Git 2.27+ выдаёт warning о неоднозначности
стратегии при каждом `git pull`. По умолчанию pull всё равно
отрабатывает (merge), но дёргает - чтобы выбор был осознанный.
Поставь `pull.rebase` или `pull.ff` в конфиг, и предупреждение
пропадёт.

## --ff-only

Самый безопасный вариант:

```bash
git pull --ff-only
```

Затащит обновления, только если можно fast-forward. Если у тебя
локально есть несмерженные коммиты - откажет, придётся решать
вручную (merge или rebase). Это предотвращает случайные
merge-коммиты от инерции.

## Что делает physically

1. `git fetch origin` - скачивает все новые объекты в `.git/objects/`
   и обновляет `origin/<branches>` (это refs/remotes/origin/...).
2. Берёт remote tracking branch (`origin/main`) и сравнивает с
   локальной (`main`).
3. Запускает merge (или rebase) FETCH_HEAD в текущую ветку.

Локальная история пишется только на шаге 3. До этого `git fetch`
можно вызывать сколько угодно - он безопасен.

## Подводные камни

- `git pull` с unstaged изменениями в файлах, которые меняет
  remote, отвалится с ошибкой. Решение - stash перед pull или
  закоммитить.
- При отсутствии tracking-ветки `git pull` без аргументов не
  работает. Нужно явно: `git pull origin main`.
- `git pull --rebase` на ветке с уже запушенными коммитами
  переписывает их SHA. Это значит, что следующий push потребует
  `--force-with-lease`. Не делай это для веток, которые видят
  другие люди.


## Команды

```bash
git pull
```
fetch + merge (или rebase, по конфигу)

```bash
git pull --rebase
```
Затащить удалённое и переписать локальные коммиты поверх

```bash
git pull --ff-only
```
Только fast-forward, отказ при расхождении

```bash
git fetch && git merge origin/main
```
Эквивалент pull, но с возможностью посмотреть до merge


## См. также

- [git push](/courses/git/kb/push.md)
- [git merge](/courses/git/kb/merge.md)
- [Ветка (branch)](/courses/git/kb/branch.md)