Rebase: mi ez, miben különbözik a Merge-től és működési elve

Mi az a Rebase?

Rebase (átalapozás) — egy Git művelet, amely az aktuális ágból commitokat helyez át egy új referenciapontra (alapra). Ahelyett, hogy merge commitot hozna létre, a rebase minden egyes commitot a forráságból sorban alkalmaz az új alapra. Az eredmény egy lineáris commitsorozat elágazások nélkül.

A rebase név a „re-base" — alap megváltoztatása kifejezésből származik. Ha a merge két ágat egy pontban egyesít, a rebase valójában az egész ágat egy új helyre mozgatja, azt a látszatot keltve, mintha a célág aktuális állapotáról kezdte volna a fejlesztést. Ez a tökéletesen szekvenciális munka illúzióját kelti.

A Atlassian, 2025 adatai szerint a rebase-t használó csapatok a feature ágakhoz 30%-kal kevesebb időt töltenek a commit történet elemzésével, mint a kizárólag merge-t használó csapatok. A lineáris történet leegyszerűsíti a git blame, bisect és a napló megtekintését a git log --oneline segítségével.

Alapvető különbség a Merge-től

Merge egyesíti az ágakat egy két szülővel rendelkező commit létrehozásával. Rebase átírja a történetet: az új commitok újra létrejönnek új hash-ekkel, bár a változtatások azonosak az eredetiekkel. Ez azt jelenti, hogy a rebase megváltoztatja a commitok SHA azonosítóit, ami kritikus a nyilvános ágaknál.

Hogyan működik a Rebase

A rebase mechanizmusa négy lépésből áll: a Git meghatározza az aktuális és a célág közös ősét (merge base), majd sorban alkalmazza az aktuális ág minden commitját a célágra. Ha valamelyik lépésnél konfliktus lép fel — a rebase megáll és vár a megoldásra.

# Kezdeti helyzet: a feature 3 committal elmarad a develop-tól
git checkout feature/new-login
git rebase develop

# A Git 3 commitot vesz a feature-ből és alkalmazza a develop-ra
# Ha nincs konfliktus — a rebase automatikusan befejeződik
# Ha van — a Git megáll a konfliktusos commitnál

A rebase után a feature ág tartalmazza az összes commitot a develop-ból plusz a saját commitjait, amelyek a develop folytatásának tűnnek. Ez lehetővé teszi a develop-ba történő egyesítést fast-forward segítségével, merge commit létrehozása nélkül.

Lépésről lépésre folyamat

Tekintsünk egy részletes példát: egy fejlesztő létrehozott egy feature ágat a develop-ból, két commitot végzett, és eközben más fejlesztők három commitot adtak a develop-hoz. A rebase áthelyezi a feature két commitját egy új helyre, új SHA-val ellátott másolatokat hozva létre.

# 1. Feature ág létrehozása
git checkout -b feature/payment-refactor develop

# 2. Commitok készítése a feature-ben
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Develop frissítése (kollégák munkája)
git checkout develop
git pull

# 4. Feature rebase-e az új develop-ra
git checkout feature/payment-refactor
git rebase develop

# 5. Most a feature fast-forward segítségével egyesíthető
git checkout develop
git merge feature/payment-refactor

Ha a 4. lépésnél konfliktus lép fel, a Git megáll a problémás commitnál. A fejlesztő feloldja a konfliktust, végrehajt egy git add-et és elindítja a git rebase --continue-t. Ha ki kell hagyni egy commitot — git rebase --skip, ha az egész rebase-t törölni — git rebase --abort.

Üres commitok automatikus kihagyása

A --empty zászló szabályozza a rebase viselkedését üres commitok esetén — olyan helyzetekben, amikor a commit összes változtatása már jelen van a célágban. Alapértelmezés szerint a rebase megáll és döntést kér. A --empty=drop zászlóval a Git automatikusan kihagyja az ilyen commitokat megállás nélkül, ami felgyorsítja a tömeges átalapozást nagyszámú commit esetén.

Interaktív Rebase

Interactive rebase (git rebase -i) — egy hatékony eszköz a commit történet szerkesztéséhez. Megnyit egy szerkesztőt a commitok listájával és kulcsfontosságú parancsokkal: pick (megtartás), reword (üzenet módosítása), edit (tartalom módosítása), squash (összevonás az előzővel), fixup (összevonás üzenet nélkül), drop (törlés).

# Az utolsó 4 commit interaktív rebase-e
git rebase -i HEAD~4

# A szerkesztőben megnyílik a rebase terv:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Módosítjuk erre:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Eredmény: három commit (bejelentkező képernyő, érvényesítés, elrendezés) egybe tömörül, a megjegyzéseket tartalmazó commit pedig törlődik. Ez lehetővé teszi egy tiszta történet bemutatását vázlatok és javítások nélkül a kód áttekintéshez. Az interactive rebase a feature ág Pull Request előtti előkészítésének szabványos eszköze.

Rebase vs Merge: összehasonlítás

Rebase és Merge ugyanazt a feladatot oldja meg — a változtatások integrálását — de alapvetően különböző módon. A kettő közötti választás attól függ, hogy milyen történetet szeretne látni a git log-ban és ki más dolgozik még az Ön ágával.

Gyakorlati szabály: használjon merge-t a közös ágakba (develop, main) történő integráláshoz és rebase-t a személyes feature ágak aktuális állapotra hozásához. Sok csapat kombinálja: rebase feature a develop-ra, majd --no-ff merge a develop-ba.

Hatás a git bisect-re

Git bisect — egy eszköz a regressziót okozó commit megtalálásához. Merge használatakor a git bisect helyesen halad át a merge commitokon, figyelembe véve mindkét szülőt. Rebase esetén a bisect gyorsabban működik, mivel a történet lineáris és nem igényel elágazást. Azonban ha a rebase-t azután végezték, hogy a commitok ismertté váltak a csapat számára, az eredeti SHA-k elvesznek, és a bisect nem biztos, hogy megtalálja a problémás commitot.

Mikor alkalmazzuk a Rebase-t

Rebase három forgatókönyvben optimális: a feature ág előkészítése Pull Request-hez, a személyes ág frissítése a main/develop aktuális állapotára és a történet tisztítása az egyesítés előtt. Minden esetben a rebase javítja a történet olvashatóságát a csapatmunka kockáztatása nélkül.

Pull Request előtt ajánlott interaktív rebase-t végezni, hogy a munka commitokat (WIP, javítások áttekintés után) értelmes logikai egységekbe vonja össze. Ez megkönnyíti a kód áttekintést: a felülvizsgáló nem 15 apró commitot lát, hanem 3-5 strukturált változtatást érthető üzenetekkel.

A feature ág frissítéséhez a rebase előnyösebb a merge-nél, mert nem hoz létre felesleges merge commitokat. Ha időnként git rebase develop-t végez a feature ágon belül, a végső egyesítés után nem lesz 10 merge commitből álló kaszkád — csak tiszta funkció commitok a develop-on.

A történet tisztítása interaktív rebase segítségével az egyesítés előtt lehetővé teszi a kisebb javítások (gépelési hibák, formázás) elrejtését és a commitok funkció szerinti csoportosítását. A Git üzeneteknek követniük kell a Conventional Commits egyezményt (fix:, feat:, refactor:, docs:), ami automatikus changelog-ot generál.

A Rebase kockázatai és szabályai

Rebase — veszélyes művelet, ha helytelenül alkalmazzák. A fő kockázat — a közzétett történet átírása. Ha egy fejlesztő rebase-t végez egy olyan ágon, amelyet mások már pusholtak és használnak, a helyi másolatok deszinkronizálódnak, és force-pull-t kell végrehajtaniuk az adatvesztés kockázatával.

• Aranyszabály: soha ne rebaselj olyan commitokat, amelyek már léteznek a megosztott tárolóban. Ez vonatkozik minden olyan ágra, amelyhez a csapat más tagjai hozzáférnek
• Force push: a helyi feature ág rebase-je után push szükséges a --force-with-lease zászlóval, ami biztonságosabb a --force-nál, mert ellenőrzi, hogy valaki frissítette-e az ágat a szerveren
• Kontextus elvesztése: a rebase megsemmisíti az információt arról, hogy mikor és melyik ágból hozták létre a feature ágat. Ha fontos megőrizni az ág létrehozásának dátumát — használjon merge-t
• Konfliktusok: rebase esetén a konfliktusokat minden egyes commitnál külön kell feloldani, ami fárasztó lehet nagyszámú commit esetén

A kockázatok minimalizálásához tartsa be a szabályt: rebase csak személyes ágakhoz, amelyek nem lettek közzétéve. Ha az ág már a megosztott tárolóban van — használjon merge-t --no-ff-fel. Ha szükséges egy közzétett ág rebase-je — figyelmeztesse a csapatot és egyeztesse a force push-t előre.

Automatikus védelem a veszélyes rebase ellen server-side hookokon keresztül valósul meg: a Git szerver oldali pre-receive hook ellenőrizheti, hogy a push átír-e közzétett commitokat. A GitHub és a GitLab beépített védelmet nyújt a védett ágak számára — a force push blokkolva van, hacsak az adminisztrátor el nem távolítja a védelmet.