Rebase: що це, чим відрізняється від Merge та принцип роботи

Що таке Rebase?

Rebase (перебазування) — це операція Git, яка переносить коміти з поточної гілки на нову точку відліку (базу). Замість створення merge commit, rebase бере кожен коміт із вихідної гілки та по черзі застосовує його поверх нової бази. У результаті виходить лінійна послідовність комітів без розгалужень.

Назва rebase походить від «re-base» — змінити базу. Якщо merge об’єднує дві гілки в одній точці, то rebase фактично переносить вашу гілку цілком на нове місце, створюючи враження, ніби ви почали розробку від актуального стану цільової гілки. Це створює ілюзію ідеально послідовної роботи.

За даними Atlassian, 2025, команди, які використовують rebase для функціональних гілок, витрачають на 30% менше часу на аналіз історії комітів порівняно з командами, які використовують виключно merge. Лінійна історія спрощує git blame, bisect і перегляд логу через git log --oneline.

Принципова відмінність від Merge

Merge об’єднує гілки, створюючи коміт із двома батьками. Rebase переписує історію: нові коміти створюються заново з новими хешами, хоча зміни в них ідентичні вихідним. Це означає, що rebase змінює SHA-ідентифікатори комітів, що критично для публічних гілок.

Як працює Rebase

Механізм rebase складається з чотирьох кроків: Git визначає спільного предка (merge base) поточної та цільової гілки, потім послідовно застосовує кожен коміт поточної гілки поверх цільової. Якщо на якомусь кроці виникає конфлікт — rebase зупиняється та чекає на вирішення.

# Стартова ситуація: feature відстала від develop на 3 коміти
git checkout feature/new-login
git rebase develop

# Git бере 3 коміти з feature і застосовує їх поверх develop
# Якщо конфліктів немає — rebase завершується автоматично
# Якщо є — Git зупиняється на конфліктному коміті

Після rebase функціональна гілка містить усі коміти з develop плюс свої власні коміти, які виглядають як продовження develop. Це дозволяє зробити merge у develop через fast-forward без створення merge commit.

Покроковий процес

Розглянемо детальний приклад: розробник створив функціональну гілку від develop, зробив два коміти, а за цей час в develop додали три коміти інші розробники. Rebase перенесе два коміти функціональної гілки на нове місце, створивши їхні копії з новими SHA.

# 1. Створити feature-гілку
git checkout -b feature/payment-refactor develop

# 2. Зробити коміти у feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Оновити develop (робота колег)
git checkout develop
git pull

# 4. Перебазувати feature поверх нового develop
git checkout feature/payment-refactor
git rebase develop

# 5. Тепер feature можна злити через fast-forward
git checkout develop
git merge feature/payment-refactor

Якщо на кроці 4 виникає конфлікт, Git зупиняється на проблемному коміті. Розробник вирішує конфлікт, робить git add і виконує git rebase --continue. Якщо потрібно пропустити коміт — git rebase --skip, якщо скасувати весь rebase — git rebase --abort.

Автоматичне пропускання порожніх комітів

Прапорець --empty керує поведінкою rebase при порожніх комітах — ситуаціях, коли всі зміни коміту вже присутні в цільовій гілці. За замовчуванням rebase зупиняється та запитує рішення. З прапорцем --empty=drop Git автоматично пропускає такі коміти без зупинки, що прискорює масове перебазування з великою кількістю комітів.

Інтерактивний Rebase

Інтерактивний rebase (git rebase -i) — потужний інструмент для редагування історії комітів. Він відкриває редактор зі списком комітів та ключовими командами: pick (залишити), reword (змінити повідомлення), edit (змінити вміст), squash (об’єднати з попереднім), fixup (об’єднати без повідомлення), drop (видалити).

# Інтерактивний rebase останніх 4 комітів
git rebase -i HEAD~4

# У редакторі відкриється план rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Змінюємо на:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Результат: три коміти (login screen, validation, layout) стиснуті в один, а коміт з коментарями видалено. Це дозволяє подавати на код-рев’ю чисту історію без чернеток і виправлень. Інтерактивний rebase — стандартний інструмент підготовки функціональної гілки перед Pull Request.

Rebase vs Merge: порівняння

Rebase і Merge вирішують одне завдання — інтеграцію змін — але принципово різними способами. Вибір між ними залежить від того, яку історію ви хочете бачити в git log і хто ще працює з вашою гілкою.

Практичне правило: використовуйте merge для інтеграції в спільні гілки (develop, main) і rebase для приведення особистих функціональних гілок до актуального стану. Багато команд комбінують: rebase функціональної гілки на develop, потім --no-ff merge у develop.

Вплив на git bisect

Git bisect — інструмент для пошуку коміту, який вніс регресію. При використанні merge git bisect коректно проходить через merge commit, враховуючи обох батьків. При rebase bisect працює швидше, оскільки історія лінійна та не потребує розгалуження. Однак якщо rebase було зроблено після того, як коміти стали відомі команді, вихідні SHA втрачаються, і bisect може не знайти проблемний коміт.

Коли застосовувати Rebase

Rebase оптимальний у трьох сценаріях: підготовка функціональної гілки до Pull Request, оновлення особистої гілки до актуального стану main/develop і очищення історії перед злиттям. У кожному випадку rebase покращує читабельність історії без ризику для командної роботи.

Перед Pull Request рекомендується виконати інтерактивний rebase, щоб об’єднати чернеткові коміти (WIP, виправлення після рев’ю) в осмислені логічні одиниці. Це полегшує код-рев’ю: рев’юер бачить не 15 дрібних комітів, а 3-5 структурованих змін зі зрозумілими повідомленнями.

Для оновлення функціональної гілки rebate кращий за merge, тому що він не створює зайвих merge commit. Якщо періодично робити git rebase develop всередині функціональної гілки, після фінального злиття не буде каскаду з 10 merge commit — лише чисті коміти функціональної гілки поверх develop.

Очищення історії через інтерактивний rebase перед merge дозволяє приховати незначні виправлення (друкарські помилки, форматування) і згрупувати коміти за функціональністю. Git-повідомлення мають слідувати угоді Conventional Commits (fix:, feat:, refactor:, docs:), що генерує автоматичний changelog.

Ризики та правила Rebase

Rebase — небезпечна операція, якщо застосовувати її неправильно. Головний ризик — переписування опублікованої історії. Якщо розробник зробив rebase гілки, яку інші вже запушили та використовують, їхні локальні копії розсинхронізуються, і їм доведеться виконувати force-pull із ризиком втрати даних.

• Golden Rule: ніколи не робіть rebase комітів, які вже існують у спільному репозиторії. Це стосується будь-яких гілок, до яких мають доступ інші учасники команди
• Force push: після rebase локальної функціональної гілки потрібен push з прапорцем --force-with-lease, який безпечніший за --force, оскільки перевіряє, чи не оновив хтось гілку на сервері
• Втрата контексту: rebase знищує інформацію про те, коли та від якої гілки створювалася функціональна гілка. Якщо важливо зберегти дати створення гілки — використовуйте merge
• Конфлікти: при rebase конфлікти потрібно вирішувати для кожного коміту окремо, що може бути стомлювано при великій кількості комітів

Для мінімізації ризиків дотримуйтеся правила: rebase тільки для особистих гілок, які не були опубліковані. Якщо гілка вже у спільному репозиторії — використовуйте merge з --no-ff. При необхідності rebase опублікованої гілки — попередьте команду та погодьте force push заздалегідь.

Автоматичний захист від небезпечного rebase реалізується через server-side hooks: pre-receive hook на стороні Git-сервера може перевіряти, чи не переписує push опубліковані коміти. GitHub і GitLab надають вбудований захист для protected branch — force push блокується, якщо захист не знято адміністратором.