Git sync fork з upstream: 3 безпечні способи

TL;DR: виконайте git fetch upstream && git merge upstream/main && git push origin main — і ваш fork наздогнав. Це весь робочий процес «git sync fork з upstream» одним рядком: підтягнути зміни з проєкту, який ви форкнули, і запушити їх у свою копію. Якщо любите лінійну історію — замініть merge на git rebase upstream/main і зробіть force-push. А якщо remote upstream ви взагалі ще не підключали, почніть із кроку 1 нижче: саме відсутній remote — причина номер один «fork не синхронізується». Усе інше — rebase, кнопка синхронізації GitHub, розбіжні гілки, що не пушаться — деталі поверх цих трьох команд.

Що означає синхронізувати fork з upstream?

Fork — це ваша копія чужого репозиторію на GitHub. Оригінал — це upstream; ваша копія — origin. GitHub-форки не оновлюються самі: коли мейнтейнери мержать pull request, ваша копія лишається з учорашнім кодом. Синхронізація fork означає підтягнути нові коміти з upstream у ваш fork, щоб гілка збігалася з поточним станом проєкту або хоча б містила його.

Це важливо з двох причин. По-перше, внески: кожен pull request зі старого fork несе зайвий шум, і мейнтейнери попросять оновитися перед мержем. По-друге, самостійний хостинг чи вивчення: якщо ви запускаєте fork у проді чи просто читаєте код, місячний fork — це місяць виправлень багів, яких у вас немає.

Як синхронізувати fork з upstream з командного рядка?

Три кроки: раз оголосити upstream, підтягнути з нього, потім змержити і запушити. Підключення — назавжди; наступного разу ви набираєте лише кроки 2 і 3.

Крок 1 — додайте upstream remote (один раз на клон).

# всередині вашого локального клона форка
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # перевірте: origin -> ваш fork, upstream -> оригінал

Правильну адресу шукайте на сторінці оригінального репозиторію: зелена кнопка Code. Часта помилка — показати обидва remote на свій fork: тоді «синхронізація» мовчки нічого не робить, бо ви тягнете з копії, настільки ж застарілої, як ваша власна.

Крок 2 — підтягніть і змержіть гілку upstream.

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

Це стандартна відповідь на «git sync fork з upstream у командному рядку». Типовий результат — fast-forward: ваш main нічого нового не мав, тому просто з’їжджає до upstream/main, і merge-коміт не створюється.

Крок 3 — повторюйте за потреби. Пам’ятати нічого, крім git fetch upstream && git merge upstream/main && git push origin main. Щоб перед мержем побачити, наскільки ви відстали, виконайте після fetch: git rev-list --count main..upstream/main.

Що обрати під час синхронізації: rebase чи merge?

Обидва приносять у fork той самий код; різниця — в історії, яку вони лишають. Оберіть одну політику на репозиторій і тримайтеся її:

Спосіб	Команда	Результат історії	Найкраще для
Merge	git merge upstream/main	Зайвий merge-коміт на розбіжних гілках	Feature-гілки з відкритими PR — нічого не переписує
Rebase	git rebase upstream/main	Ваші коміти переіграні зверху, лінійна історія	Чистий main у форку; розбіжні форки, які хочете скинути
UI GitHub	Кнопка Sync branch / мерж PR	Як і merge	Швидке наздоганяння без відкритого клона

Варіант синхронізації через rebase:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Force push обов’язковий, бо rebase переписує ID комітів — віддалена гілка форку більше не походить від вашої локальної. Завжди обирайте --force-with-lease замість --force: вона відмовляється перезаписувати віддалену гілку, якщо хтось (чи ще одна ваша машина) запушив у проміжку — це робить небезпечну команду безпечною за замовчуванням.

Правило, гідне татуювання на зап’ясті: ніколи не робіть rebase гілки з відкритим pull request, якщо не впевнені у своїх діях — rebase змінює ID комітів, через що відкритий PR може відчепитися від своїх комітів. Синхронізуйте main через merge (чи зробіть rebase до початку нової роботи), а PR-гілки тримайте осторонь.

Чому мій fork не синхронізується з upstream?

Чотири звичайні підозрювані в порядку появи в реальних терміналах:

1. Немає remote upstream — git remote -v показує лише origin. Симптом: git fetch upstream падає з 'upstream' does not appear to be a git repository. Виправлення: крок 1 вище.
2. Підтягнули, але не змержили — fetch оновлює upstream/main у локальному репозиторії, але не торкається жодної робочої гілки. Симптом: git log виглядає старим після успішного fetch. Виправлення: git merge upstream/main.
3. Розбіжна історія — ви комітили у свій main, а upstream теж пішов уперед. Тоді git pull скаржиться на непов’язані історії чи наполягає на мержі. Виправлення, якщо хочете, щоб переміг upstream: git reset --hard upstream/main (викидає ваші коміти лише у вашому main — спершу гляньте git stash list чи зробіть резервну гілку; якщо поганий reset уже стався, шлях відновлення той самий, що в git undo last commit: git reflog ще пам’ятає стару вершину).
4. Push відхилено як не-fast-forward після rebase — зробили rebase, але запушували звичайно. Виправлення: git push --force-with-lease origin main.

П’ятий, рідкісний випадок: оригінальний репозиторій перейменували чи видалили, і навіть адреса з кроку 1 повертає 404. GitHub переспрямовує перейменовані репозиторії, тож тверда відмова зазвичай означає видалення чи приватність — синхронізуватися немає з чим.

Чи можна синхронізувати fork з сайту GitHub?

Так. На сторінці вашого fork у випадаючому списку гілок є кнопка Sync fork, щойно ваша гілка відстає; один клік — і upstream усередині. Нижче на сторінці те саме працює як pull request: відкрийте PR із upstream/main у main вашого форку та змержіть.

Обмеження кнопки пояснюють, коли повертатися до CLI: вона робить лише fast-forward або мерж — rebase не вміє, а за розбіжних гілок відмовляє наотріз, радячи викинути коміти чи взяти командний рядок. І синхронізує лише гілку за замовчуванням. Для всього, що складніше простого наздоганяння, інструмент — три команди вище.

Як часто синхронізувати свій fork?

Перед кожною новою роботою — чесна відповідь: гілка від свіжого main, і жоден ваш PR не починається з «це базується на версії трижовневої давнини». Для форків, яким ви активно contribутите, щоденна чи посесійна синхронізація main коштує секунди. Для форку, який ви лише читаєте чи деплоїте, — синхронізуйте, коли upstream випускає потрібне: підпишіться на релізи оригінального репозиторію й тягніть на реліз. Синхронізація дешева саме тому, що вона рутина; форк із відставанням у пів року часто вимагає хірургії, а не мержу — саме так «синхронізуй мій fork» перетворюється на цілий день.

Шпаргалка

# разовий налаштунок
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# рутинна синхронізація (політика merge)
git fetch upstream && git merge upstream/main && git push origin main

# рутинна синхронізація (політика rebase, лінійна історія)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# наскільки я відстав?
git fetch upstream && git rev-list --count main..upstream/main

# розбіжність без шансів — зробити main ідентичним upstream (руйнівно)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Тримайте рутинний дворядківець у м’язовій пам’яті — і розбіжний fork залишиться цікавістю, про яку ви читали, а не проблемою, яку ви чините. Якщо ваш git-господарський бік виходить на сервери, шпаргалка journalctl покриває другу половину справи — тримати історію машини читабельною.