Яка різниця між git fetch та git pull?

Git~3 хв читання

git fetch завантажує зміни з remote без торкання твоїх локальних гілок. git pull робить те саме завантаження, а потім одразу мерджить у поточну гілку.

Теорія

TL;DR

fetch = тільки завантаження (твоя робоча гілка не змінюється)
pull = завантаження + merge (одна команда, але без кроку перегляду)
Аналогія: fetch це перевірити поштову скриньку; pull це перевірити і одразу розкрити всі листи
Fetch коли хочеш спочатку переглянути зміни. Pull коли довіряєш remote.

Швидкий приклад

bash

# FETCH: завантажує, але не змінює твою гілку
git fetch origin
# origin/main тепер має remote коміти
# Твій локальний main: без змін

# PULL: завантажує І мерджить автоматично
git pull origin main
# Еквівалент: git fetch origin && git merge origin/main
# Твій локальний main: оновлений remote змінами

Після git fetch твій локальний main залишається там, де ти його залишив. Нові коміти потрапляють в origin/main і чекають там поки ти не вирішиш що з ними робити.

git fetch є read-only операцією. Вона оновлює remote-tracking гілки (origin/main), але не чіпає робочу директорію і локальні гілки. git pull запускає fetch і одразу git merge, що може створити конфлікти або залишити гілку в незручному стані. Fetch дає можливість подивитись перш ніж щось міняти. Pull пропускає цей крок.

Коли що використовувати

Fetch: перегляд змін перед мерджем, робота на спільній гілці, перевірка що команда запушила, або є сумніви щодо конфліктів
Pull: швидка синхронізація на особистій feature гілці, соло-розробка, або після того як CI пройшов на trusted гілці
git pull --rebase: потрібна лінійна історія без merge-комітів на feature гілці

Порівняльна таблиця

Аспект	fetch	pull	pull --rebase
Завантажує зміни	Так	Так	Так
Змінює локальну гілку	Ні	Так (merge)	Так (rebase)
Створює merge commit	Ні	Так	Ні
Ризик конфліктів	Низький	Середній	Середній
Дозволяє переглянути	Так	Ні	Ні
Коли використовувати	Перед важливими змінами	Швидкі оновлення на trusted гілках	Для лінійної історії

Типові помилки

Помилка 1: Pull на спільній гілці без попередньої перевірки

bash

# НЕПРАВИЛЬНО: сліпий pull на main
git pull origin main
# Якщо хтось запушив breaking changes, гілка одразу ламається

# ПРАВИЛЬНО: fetch, перевірити, потім merge
git fetch origin
git log origin/main -3
git diff main origin/main
git merge origin/main

Помилка 2: Думати що fetch оновлює локальну гілку

bash

# ПОМИЛКОВЕ припущення
git fetch origin
git log main  # Показує ТВОЇ коміти, remote змін тут немає

# ПРАВИЛЬНО: fetch оновлює origin/main, не main
git fetch origin
git log origin/main  # Remote коміти тут
git merge origin/main  # Тепер з'єднуємо

Помилка 3: Pull з незакомміченими змінами

bash

# НЕПРАВИЛЬНО: pull з незбереженою роботою
git pull origin main
# Error: Your local changes would be overwritten by merge

# ПРАВИЛЬНО: спочатку commit або stash
git stash
git pull origin main
git stash pop

Помилка 4: Повторні pull-и засмічують історію feature гілки

bash

# НЕПРАВИЛЬНО: кожен pull додає merge commit
git pull origin main  # merge commit
git pull origin main  # ще один merge commit
# Історія: F1 -> M1 -> F2 -> M2 -> F3 (важко читати в PR)

# ПРАВИЛЬНО: rebase зберігає лінійну історію
git pull --rebase origin main
# Історія: F1 -> F2 -> F3 (чиста, зрозуміла)

У реальних проєктах

Більшість команд де я працював використовують fetch на спільних гілках за замовчуванням. Ті зайві 30 секунд перегляду не раз рятували від годин дебагу зламаного мерджу.

Feature гілки: fetch перед тим як тягнути main у свою гілку, щоб побачити конфлікти завчасно
Deployment гілки: pull після того як CI пройшов; fetch на feature гілках для перегляду
Monorepo: fetch щоб перевірити чи зміни інших команд впливають на твій workspace
GitHub pull requests: reviewers бачать зміни без мерджу до approval, це fetch-поведінка за своєю суттю

Питання на співбесіді

Q: Що станеться якщо зробити pull і виникне конфлікт?

A: Git зупиняє merge, позначає файли з конфліктами і залишає гілку у стані "merging". Конфлікти вирішуються вручну, потім git add і git commit для завершення.

Q: Навіщо взагалі pull якщо fetch безпечніший?

A: Pull швидший для ситуацій з низьким ризиком. На особистій гілці після пройденого CI крок перегляду тільки гальмує без реальної користі. Більшість команд: fetch на спільних гілках, pull на особистих.

Q: Чим git pull --rebase відрізняється від звичайного git pull?

A: Замість merge commit, rebase накладає твої локальні коміти поверх remote гілки. Історія залишається лінійною. Підходить для feature гілок, але не роби rebase комітів вже запушених на спільні гілки, це переписує історію.

Q: Якщо зробити fetch і ніколи не мерджити, що станеться з remote змінами?

A: Вони залишаються в origin/main скільки завгодно. Локальна гілка не змінюється. Переглянути можна будь-коли через git log origin/main або git diff main origin/main.

Q: Як перевірити чи гілка відстає від remote?

A: Після git fetch запусти git log --oneline main..origin/main. Порожній вивід означає що все актуально. Будь-які коміти у виводі це те чого тобі не вистачає.

Приклади

Безпечний fetch workflow перед мерджем

Команда запушила оновлення до main і треба підтягнути їх у feature гілку без сюрпризів.

bash

# Крок 1: fetch щоб побачити що змінилось
git fetch origin

# Крок 2: переглянути commit messages
git log origin/main --oneline -5
# a1b2c3d Fix: handle null values in parser
# d4e5f6g Feat: add caching layer

# Крок 3: перевірити точні зміни коду
git diff main origin/main

# Крок 4: мерджити коли впевнений
git merge origin/main

Займає приблизно 30 зайвих секунд. Зламаний merge може потребувати набагато більше часу щоб розплутати.

Розбіжні гілки (diverged branches)

Ти закомітив локально поки в remote теж з'явились нові коміти. Це стан розбіжності (diverged).

bash

# Remote:    A -> B -> C
# Локально:  A -> B -> D  (ти закомітив D)

# Варіант 1: git pull створює merge commit
git pull origin main
# Результат: A -> B -> C
#                  \   /
#               merge commit
# C і D об'єднані

# Варіант 2: git pull --rebase для лінійної історії
git pull --rebase origin main
# Результат: A -> B -> C -> D
# Твій D накладається поверх C
# Чистіше для code review, але хеш коміту змінюється

Багато команд обирають rebase варіант для feature гілок, бо в PR так простіше читати і переглядати зміни.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Дочитали статтю?