Rebase: що це, як виконується rebase та робота з Git

Що таке rebase в Git

Rebase — це команда Git, яка перебазує поточну гілку на зазначену: бере всі коміти поточної гілки, тимчасово зберігає їх, переміщує вказівник гілки на цільовий коміт і послідовно застосовує збережені коміти поверх нього. Результат — історія виглядає так, ніби розробник вів роботу безпосередньо від останнього коміту цільової гілки.

Основний синтаксис: git rebase main — перебуваючи в feature-гілці, ця команда переносить всі feature-коміти на вершину main. Git використовує стратегію three-way merge для кожного коміту окремо. Якщо коміт A вже присутній в цільовій гілці (визначається за хешем), Git автоматично пропускає його, що дозволяє уникнути дублювання змін.

Rebase також підтримує onto-режим для перенесення частини комітів: git rebase --onto target start end — ця форма дозволяє виділити діапазон комітів з однієї гілки та застосувати їх поверх іншої. Наприклад, git rebase --onto main feature~3 feature переносить останні три коміти гілки feature поверх main.

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: ключові відмінності

Rebase та merge вирішують одне завдання — об’єднання змін з різних гілок — але роблять це принципово різними способами. Merge зберігає повну історію злиття, створюючи merge-коміт з двома батьками. Rebase перезаписує історію, роблячи її лінійною. Вибір між ними залежить від workflow команди та правил роботи з репозиторієм.

Основна відмінність — як фіксується факт злиття. Merge зберігає: «в цій точці ми об’єднали feature в main» — це інформативно для історії проекту, але засмічує лог при частих злиттях. Rebase показує: «коміти feature були зроблені послідовно від останнього стану main» — це чисто, але приховує той факт, що розробка велася паралельно.

Друга відмінність — обробка конфліктів. При merge конфлікти вирішуються один раз, і рішення фіксується в merge-коміті. При rebase конфлікти можуть виникнути для кожного перенесеного коміту, і кожен вимагає окремого вирішення. Це більш трудомістко, але дозволяє точніше контролювати, які зміни потрапляють в підсумкову версію.

Інтерактивний rebase: команди та прапорці

Інтерактивний rebase (git rebase -i) — це режим, при якому Git відкриває редактор зі списком комітів та доступними діями для кожного з них. Розробник може переписати історію перед відправленням у віддалений репозиторій. Це основний інструмент для підтримки чистоти комітів в feature-гілці.

Доступні команди в інтерактивному режимі: pick (залишити коміт як є), reword (змінити повідомлення коміту), edit (зупинитися для змін), squash (об’єднати з попереднім комітом, зберігши обидва повідомлення), fixup (об’єднати, відкинувши повідомлення), drop (видалити коміт). Кожна команда вказується перед хешем коміту в відкритому редакторі.

Squash та fixup — найчастіше використовувані команди для об’єднання комітів. Якщо розробник зробив 5 дрібних комітів з правками в процесі роботи, squash об’єднає їх в один логічний коміт з осмисленим повідомленням. Fixup корисний для виправлення друкарських помилок: зміни потрапляють у попередній коміт без збереження свого повідомлення.

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

Прапорець --autosquash автоматично розставляє fixup/squash для комітів, повідомлення яких починаються з fixup! або squash!. Це прискорює роботу, якщо розробник заздалегідь маркує коміти для подальшого об’єднання. Прапорець --committer-date-is-author-date зберігає оригінальну дату коміту при перебазуванні — корисно для збереження часової хронології в історії.

Вирішення конфліктів при rebase

Конфлікти при rebase виникають, коли Git не може автоматично застосувати перенесений коміт через протиріччя з змінами в цільовій гілці. На відміну від merge, де конфлікт вирішується один раз, при rebase кожен коміт може викликати конфлікт, і його потрібно вирішувати послідовно для кожного коміту від найстарішого до найновішого.

Коли виникає конфлікт, Git призупиняє rebase та повідомляє, який коміт викликав проблему. Розробник відкриває конфліктний файл (Git позначає конфліктні ділянки маркерами <<<<<<<, =======, >>>>>>>), редагує його, додає до індексу (git add) та продовжує rebase командою git rebase --continue. Якщо рішення не знайдено — git rebase --abort повністю скасовує перебазування.

Порада: при множинних конфліктах ефективніше використовувати git mergetool, який відкриває візуальний редактор для вирішення конфліктів. Також можна пропустити проблемний коміт (git rebase --skip), але це видалить його зміни з підсумкової історії, що рідко буває правильним рішенням.

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

Коли не можна робити rebase

Золоте правило rebase: ніколи не перебазуйте коміти, які вже були відправлені до віддаленого репозиторію та доступні іншим розробникам. Оскільки rebase перезаписує хеші комітів, у колег виникнуть конфлікти при спробі синхронізації — їхня локальна історія буде розходитися з переписаною віддаленою.

Ситуація, в якій rebase категорично заборонено: якщо хтось вже створив гілку на основі ваших комітів (наприклад, ваш колега зробив гілку від вашої feature), переписування історії зламає його роботу. В таких випадках слід використовувати merge. Також не рекомендується робити rebase прямо перед дедлайном — помилка при вирішенні конфліктів може зайняти більше часу, ніж очікувалося, та заблокувати реліз.

Виняток: якщо гілка використовується лише одним розробником (особиста feature-гілка, не опублікована або опублікована в draft-режимі), rebase до пушу — стандартна практика. Після публікації та початку колективної роботи — тільки merge. GitHub та GitLab типово пропонують squash merge як компроміс: він об’єднує коміти в один, але не перезаписує історію цільової гілки.

• Публічні гілки (main, develop, release) — rebase заборонено повністю.
• Чужі коміти — якщо гілка містить коміти іншого розробника, rebase недопустимий.
• Перед релізом — ризики конфліктів вищі: merge безпечніше за день до дедлайну.
• Гілки з тегами — переміщення коміту з тегом порушує конвенції семантичного версіонування.
• CI/CD прив’язаний до хешів — деякі системи розгортання ідентифікують збірки за хешем коміту; rebase зламає відстеження.

Практичний workflow з rebase

У сучасних командах найчастіше використовується rebase-орієнтований workflow разом з GitHub Flow. Процес виглядає так: розробник створює feature-гілку від main, працює в ній, періодично синхронізується через git rebase main, а перед створенням pull request виконує інтерактивний rebase для очищення історії.

Після створення PR (якщо потрібно підтягнути нові зміни з main) використовується git pull --rebase main замість звичайного git pull. Це дозволяє підтягнути зміни без створення зайвого merge-коміту. Git pull з прапорцем --rebase еквівалентний git fetch + git rebase — Git спочатку завантажує нові коміти, потім перебазує локальні зміни поверх них.

Git дозволяє налаштувати rebase як поведінку за замовчуванням для pull: git config --global pull.rebase true. Після цієї налаштування git pull завжди виконує rebase замість merge. Якщо потрібен звичайний pull — використовується git pull --no-rebase. Багато команд також вмикають autostash: git config --global rebase.autoStash true — це автоматично ховає незакомічені зміни перед rebase та відновлює їх після.