Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Яка різниця між git fetch та git pull?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**git fetch** завантажує remote зміни без змін локальної гілки. **git pull** запускає fetch і merge автоматично. ```bash git fetch origin # origin/main оновлюється, твоя гілка ні git pull origin main # те саме що: git fetch + git merge ``` **Ключове:** fetch коли хочеш переглянути зміни перед інтеграцією; pull для швидких оновлень на trusted гілках.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**`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 так простіше читати і переглядати зміни.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.