Rebase: шта је то, по чему се разликује од Merge и принцип рада

Шта је Rebase?

Rebase (пребазирање) — је Git операција која преноси комитове из тренутне гране на нову тачку ослонца (базу). Уместо да створи комит спајања, rebase узима сваки комит из изворне гране и редом га примењује преко нове базе. Резултат је линеарна секвенца комитова без гранања.

Назив rebase потиче од „re-base" — променити базу. Ако merge спаја две гране у једној тачки, rebase заправо премешта целу вашу грану на ново место, стварајући илузију да сте почели развој од актуелног стања циљне гране. Ово ствара утисак савршено секвенцијалног рада.

Према подацима Atlassian, 2025, тимови који користе rebase за feature гране троше 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, feature грана садржи све комитове из develop-а плус своје комитове, који изгледају као наставак develop-а. Ово омогућава спајање у develop путем fast-forward, без стварања комита спајања.

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

Размотримо детаљан пример: програмер је створио feature грану од develop-а, направио два комита, а за то време су други програмери додали три комита у develop. Rebase ће преместити два комита feature на ново место, стварајући њихове копије са новим 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

Interactive 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

Резултат: три комита (екран за пријаву, валидација, изглед) су сажета у један, а комит са коментарима је обрисан. Ово омогућава представљање чисте историје без нацрта и исправки за преглед кода. 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 — алат за проналажење комита који је унео регресију. При коришћењу merge, git bisect исправно пролази кроз комитове спајања, узимајући у обзир оба родитеља. При rebase, bisect ради брже јер је историја линеарна и не захтева гранање. Међутим, ако је rebase урађен након што су комитови постали познати тиму, оригинални SHA се губе и bisect можда неће пронаћи проблематични комит.

Када применити Rebase

Rebase је оптималан у три сценарија: припрема feature гране за Pull Request, ажурирање личне гране на актуелно стање main/develop и чишћење историје пре спајања. У сваком случају, rebase побољшава читљивост историје без ризика за тимски рад.

Пре Pull Request-а препоручује се извршење interactive rebase-а да би се спојили радни комитови (WIP, исправке након прегледа) у смислене логичке целине. Ово олакшава преглед кода: прегледач види не 15 ситних комитова, већ 3-5 структурисаних измена са разумљивим порукама.

За ажурирање feature гране, rebase је пожељнији од merge-а јер не ствара непотребне комитове спајања. Ако периодично радите git rebase develop унутар feature гране, након коначног спајања неће бити каскаде од 10 комитова спајања — само чисти комитови функције преко develop-а.

Чишћење историје кроз interactive rebase пре спајања омогућава скривање мањих исправки (грешке у куцању, форматирање) и груписање комитова по функционалности. Git поруке треба да прате договор Conventional Commits (fix:, feat:, refactor:, docs:), што генерише аутоматски changelog.

Ризици и правила Rebase

Rebase — опасна операција ако се примени неправилно. Главни ризик — преписивање објављене историје. Ако програмер уради rebase гране коју су други већ гурнули и користе, њихове локалне копије се десинхронизују и мораће да изврше force-pull са ризиком од губитка података.

• Златно правило: никада не радите rebase комитова који већ постоје у заједничком репозиторијуму. Ово се односи на све гране којима други чланови тима имају приступ
• Force push: након rebase локалне feature гране потребан је push са заставом --force-with-lease, која је безбеднија од --force јер проверава да ли је неко ажурирао грану на серверу
• Губитак контекста: rebase уништава информацију о томе када и од које гране је створена feature грана. Ако је важно сачувати датуме стварања гране — користите merge
• Конфликти: при rebase, конфликти се морају решавати за сваки комит појединачно, што може бити напорно при великом броју комитова

За минимизацију ризика придржавајте се правила: rebase само за личне гране које нису објављене. Ако је грана већ у заједничком репозиторијуму — користите merge са --no-ff. При потреби rebase објављене гране — упозорите тим и усагласите force push унапред.

Аутоматска заштита од опасног rebase-а се реализује кроз server-side hooks: pre-receive hook на страни Git сервера може проверавати да ли push преписује објављене комитове. GitHub и GitLab пружају уграђену заштиту за заштићене гране — force push се блокира ако заштита није уклоњена од стране администратора.