Rebase: какво е, разлика от Merge и принцип на работа

Какво е Rebase?

Rebase (пребазиране) — е Git операция, която премества commits от текущия клон на нова референтна точка (база). Вместо да създава merge commit, rebase взема всеки commit от изходния клон и го прилага последователно върху новата база. Резултатът е линейна последователност от commits без разклонения.

Името rebase произлиза от „re-base“ — промяна на базата. Ако merge обединява два клона в една точка, rebase всъщност премества целия ви клон на ново място, създавайки илюзията, че сте започнали разработката от актуалното състояние на целевия клон. Това създава впечатление за перфектно последователна работа.

Според данни от Atlassian, 2025, екипите, които използват rebase за feature клонове, харчат 30% по-малко време за анализ на историята на commits в сравнение с екипите, които използват само merge. Линейната история опростява git blame, bisect и прегледа на лога чрез git log --oneline.

Основна разлика от Merge

Merge обединява клонове, създавайки commit с двама родители. Rebase презаписва историята: нови commits се създават наново с нови hash-ове, въпреки че промените в тях са идентични с оригиналните. Това означава, че rebase променя SHA идентификаторите на commits, което е критично за публичните клонове.

Как работи Rebase

Механизмът на rebase се състои от четири стъпки: Git определя общия прародител (merge base) на текущия и целевия клон, след което последователно прилага всеки commit от текущия клон върху целевия клон. Ако на някоя стъпка възникне конфликт — rebase спира и чака решение.

# Начална ситуация: feature изостава от develop с 3 commits
git checkout feature/new-login
git rebase develop

# Git взема 3 commits от feature и ги прилага върху develop
# Ако няма конфликти — rebase завършва автоматично
# Ако има — Git спира на конфликтния commit

След rebase, feature клонът съдържа всички commits от develop плюс своите собствени commits, които изглеждат като продължение на develop. Това позволява сливане в develop чрез fast-forward, без създаване на merge commit.

Процес стъпка по стъпка

Нека разгледаме подробен пример: програмист създаде feature клон от develop, направи два commits, а междувременно други програмисти добавиха три commits в develop. Rebase ще премести двата commits на feature на ново място, създавайки техни копия с нови SHA.

# 1. Създаване на feature клон
git checkout -b feature/payment-refactor develop

# 2. Правене на commits във 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 спира на проблемния commit. Програмистът разрешава конфликта, прави git add и изпълнява git rebase --continue. Ако трябва да се пропусне commit — git rebase --skip, ако да се отмени целият rebase — git rebase --abort.

Автоматично пропускане на празни commits

Флагът --empty управлява поведението на rebase при празни commits — ситуации, при които всички промени на commit-а вече присъстват в целевия клон. По подразбиране rebase спира и иска решение. С флага --empty=drop Git автоматично пропуска такива commits без спиране, което ускорява масовото пребазиране с голям брой commits.

Интерактивен Rebase

Interactive rebase (git rebase -i) — мощен инструмент за редактиране на историята на commits. Той отваря редактор със списък от commits и ключови команди: pick (остави), reword (промени съобщението), edit (промени съдържанието), squash (слей с предишния), fixup (слей без съобщение), drop (изтрий).

# Интерактивен rebase на последните 4 commits
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

Резултат: три commits (екран за вход, валидация, оформление) са свити в един, а commit-ът с коментари е изтрит. Това позволява представянето на чиста история без чернови и корекции за преглед на код. Interactive rebase е стандартният инструмент за подготовка на feature клон преди Pull Request.

Rebase vs Merge: сравнение

Rebase и Merge решават една и съща задача — интегриране на промени — но по коренно различни начини. Изборът между тях зависи от това каква история искате да виждате в git log и кой друг работи с вашия клон.

Практическо правило: използвайте merge за интегриране в общи клонове (develop, main) и rebase за привеждане на лични feature клонове към актуално състояние. Много екипи комбинират: rebase feature върху develop, след това --no-ff merge в develop.

Влияние върху git bisect

Git bisect — инструмент за намиране на commit-а, който е въвел регресия. При използване на merge, git bisect преминава правилно през merge commits, като взема предвид и двамата родители. При rebase, bisect работи по-бързо, тъй като историята е линейна и не изисква разклонение. Въпреки това, ако rebase е направен, след като commits са станали известни на екипа, оригиналните SHA се губят и bisect може да не намери проблемния commit.

Кога да прилагаме Rebase

Rebase е оптимален в три сценария: подготовка на feature клон за Pull Request, актуализиране на личен клон до актуалното състояние на main/develop и почистване на историята преди сливане. Във всеки случай rebase подобрява четимостта на историята без риск за екипната работа.

Преди Pull Request се препоръчва извършване на interactive rebase, за да се слеят работните commits (WIP, корекции след преглед) в смислени логически единици. Това улеснява прегледа на код: рецензентът вижда не 15 малки commits, а 3-5 структурирани промени с разбираеми съобщения.

За актуализиране на feature клон, rebase е за предпочитане пред merge, тъй като не създава излишни merge commits. Ако периодично правите git rebase develop във feature клона, след крайното сливане няма да има каскада от 10 merge commits — само чисти commits на функционалността върху develop.

Почистване на историята чрез interactive rebase преди сливане позволява скриване на малки корекции (печатни грешки, форматиране) и групиране на commits по функционалност. Git съобщенията трябва да следват конвенцията Conventional Commits (fix:, feat:, refactor:, docs:), което генерира автоматичен changelog.

Рискове и правила на Rebase

Rebase — опасна операция, ако се прилага неправилно. Основният риск — презаписване на публикувана история. Ако програмист направи rebase на клон, който други вече са push-нали и използват, техните локални копия се десинхронизират и ще трябва да извършат force-pull с риск от загуба на данни.

• Златно правило: никога не правете rebase на commits, които вече съществуват в споделеното хранилище. Това се отнася за всички клонове, до които други членове на екипа имат достъп
• Force push: след rebase на локален feature клон е необходим push с флага --force-with-lease, който е по-безопасен от --force, тъй като проверява дали някой не е актуализирал клона на сървъра
• Загуба на контекст: rebase унищожава информация за това кога и от кой клон е създаден feature клонът. Ако е важно да се запазят датите на създаване на клона — използвайте merge
• Конфликти: при rebase конфликтите трябва да се разрешават за всеки commit поотделно, което може да бъде досадно при голям брой commits

За минимизиране на рисковете спазвайте правилото: rebase само за лични клонове, които не са публикувани. Ако клонът вече е в споделеното хранилище — използвайте merge с --no-ff. При необходимост от rebase на публикуван клон — предупредете екипа и съгласувайте force push предварително.

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