Rebase: mi ez, hogyan működik és munka Git-tel

Mi a rebase Git-ben

Rebase — egy Git parancs, amely az aktuális ágat a megadott ágra helyezi át: veszi az aktuális ág összes commit-ját, ideiglenesen elmenti őket, átmozgatja az ág mutatóját a cél commit-ra, és szekvenciálisan alkalmazza az elmentett commit-okat a tetejére. Az eredmény — a történet úgy néz ki, mintha a fejlesztő közvetlenül a célág utolsó commit-jától dolgozott volna.

Alapszintaxis: git rebase main — a feature-ágban tartózkodva ez a parancs az összes feature commit-ot a main tetejére helyezi. A Git minden egyes commit-hoz külön three-way merge stratégiát használ. Ha az A commit már jelen van a célágban (hash alapján meghatározva), a Git automatikusan kihagyja, ami elkerüli a változtatások duplikálását.

A rebase támogatja az onto módot is a commit-ok egy részének áthelyezéséhez: git rebase --onto target start end — ez a forma lehetővé teszi commit-ok egy tartományának kivonását az egyik ágból és alkalmazását egy másik tetejére. Például a git rebase --onto main feature~3 feature áthelyezi a feature ág utolsó három commit-ját a main tetejére.

# Válts feature ágra
git checkout feature

# Helyezd át a feature-t main-re
git rebase main

# Sikeres rebase után — a történet lineáris
git log --oneline --graph

# Helyezd át az utolsó 3 commit-ot main-re
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: fő különbségek

Rebase és merge ugyanazt a feladatot oldja meg — változtatások egyesítése különböző ágakból — de alapvetően eltérő módon. A merge megtartja a teljes egyesítési történetet, létrehozva egy merge-commit-ot két szülővel. A rebase felülírja a történetet, lineárissá téve azt. A köztük lévő választás a csapat munkafolyamatától és a repozitóriummal való munka szabályaitól függ.

A fő különbség — hogyan rögzítődik az egyesítés ténye. A merge megőrzi: „ezen a ponton egyesítettük a feature-t a main-be” — ez informatív a projekt története szempontjából, de gyakori egyesítéseknél eltömíti a naplót. A rebase megmutatja: „a feature commit-ok szekvenciálisan készültek a main utolsó állapotától” — ez tiszta, de elrejti azt a tényt, hogy a munka párhuzamosan zajlott.

A második különbség — konfliktusok kezelése. Merge-nél a konfliktusokat egyszer kell megoldani, és a megoldás rögzítésre kerül a merge-commit-ban. Rebase-nél a konfliktusok minden áthelyezett commit-nál felmerülhetnek, és mindegyik külön megoldást igényel. Ez munkaigényesebb, de pontosabb ellenőrzést tesz lehetővé arról, hogy mely változtatások kerülnek a végleges verzióba.

Interaktív rebase: parancsok és jelzők

Interaktív rebase (git rebase -i) — az a mód, amikor a Git megnyit egy szerkesztőt a commit-ok listájával és a mindegyikhez elérhető műveletekkel. A fejlesztő átírhatja a történetet a távoli repozitóriumba küldés előtt. Ez a fő eszköz a commit-ok tisztaságának megőrzésére a feature-ágban.

Elérhető parancsok az interaktív módban: pick (hagyd a commit-ot úgy, ahogy van), reword (változtasd meg a commit üzenetét), edit (állj meg a változtatásokhoz), squash (vond össze az előző commit-tal, megtartva mindkét üzenetet), fixup (vond össze az üzenet eldobásával), drop (távolítsd el a commit-ot). Minden parancsot a commit hash előtt kell megadni a megnyitott szerkesztőben.

Squash és fixup — a leggyakrabban használt parancsok a commit-ok összevonására. Ha a fejlesztő 5 kis javító commit-ot készített a munka során, a squash ezeket egyetlen logikai commit-ba vonja össze értelmes üzenettel. A fixup hasznos a gépelési hibák javításához: a változtatások az előző commit-ba kerülnek anélkül, hogy megtartanák saját üzenetüket.

# Nyisd meg a szerkesztőt az utolsó 4 commit-hoz
git rebase -i HEAD~4

# A szerkesztő megmutatja:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Mentés után — Git végrehajtja a rebase-t
# és megnyitja a szerkesztőt az egyesített commit üzenethez

# Auto-squash a szerkesztő megnyitása nélkül
git rebase -i HEAD~4 --autosquash

A --autosquash jelző automatikusan fixup/squash-t állít be azokhoz a commit-okhoz, amelyek üzenete fixup! vagy squash! szavakkal kezdődik. Ez felgyorsítja a munkát, ha a fejlesztő előre megjelöli a commit-okat a későbbi összevonáshoz. A --committer-date-is-author-date jelző megőrzi a commit eredeti dátumát az áthelyezés során — hasznos a kronológia megtartásához a történetben.

Konfliktusok megoldása rebase-nél

Konfliktusok rebase-nél akkor merülnek fel, amikor a Git nem tudja automatikusan alkalmazni az áthelyezett commit-ot a célágban lévő változtatásokkal való ellentmondás miatt. Ellentétben a merge-dzsel, ahol a konfliktust egyszer kell megoldani, a rebase-nél minden commit okozhat konfliktust, és azt szekvenciálisan kell megoldani minden commit-nál a legrégibbtől a legújabbig.

Amikor konfliktus merül fel, a Git felfüggeszti a rebase-t és jelzi, melyik commit okozta a problémát. A fejlesztő megnyitja a konfliktusos fájlt (a Git a konfliktusos területeket <<<<<<<, =======, >>>>>>> jelzőkkel jelöli), szerkeszti, hozzáadja az indexhez (git add) és folytatja a rebase-t a git rebase --continue paranccsal. Ha nem található megoldás — a git rebase --abort teljesen megszakítja az áthelyezést.

Tipp: többszörös konfliktusok esetén hatékonyabb a git mergetool használata, amely vizuális szerkesztőt nyit az ellentmondások feloldásához. A problémás commit-ot is ki lehet hagyni (git rebase --skip), de ez eltávolítja a változtatásait a végső történetből, ami ritkán a helyes megoldás.

# Rebase indítása konfliktussal
git rebase main
# Auto-merging file.txt
# KONFLIKTUS (tartalom): Egyesítési konfliktus a file.txt-ben

# Állapot ellenőrzése
git status
# mindkettő módosítva: file.txt

# Konfliktusos részek szerkesztése → git add → folytatás
git add file.txt
git rebase --continue

# Kétség esetén — szakítsd meg
git rebase --abort

Mikor nem szabad rebase-elni

A rebase arany szabálya: soha ne helyezz át olyan commit-okat, amelyeket már elküldtél a távoli repozitóriumba és más fejlesztők számára elérhetőek. Mivel a rebase felülírja a commit-ok hash-jeit, a kollégák konfliktusokba ütköznek a szinkronizálási kísérlet során — a helyi történetük eltér a felülírt távoli történettől.

Az a helyzet, amikor a rebase kategorikusan tilos: ha valaki már létrehozott egy ágat az Ön commit-jai alapján (például a kollégája készített egy feature-t az Ön feature-ából), a történet megváltoztatása tönkreteszi a munkáját. Ilyen esetekben merge-t kell használni. Szintén nem ajánlott rebase-elni közvetlenül a határidő előtt — a konfliktusok megoldása során elkövetett hiba több időt vehet igénybe a vártnál, és blokkolhatja a kiadást.

Kivétel: ha az ágat csak egy fejlesztő használja (személyes feature-ág, nem publikált vagy draft módban publikált), a push előtti rebase szokásos gyakorlat. Publikálás és a kollektív munka megkezdése után — csak merge. A GitHub és GitLab alapértelmezés szerint a squash merge-t kínálja kompromisszumként: egyesíti a commit-okat egybe, de nem írja felül a célág történetét.

• Nyilvános ágak (main, develop, release) — a rebase teljesen tilos.
• Mások commit-jai — ha az ág más fejlesztő commit-jait tartalmazza, a rebase elfogadhatatlan.
• Kiadás előtt — a konfliktusok kockázata magasabb: a merge biztonságosabb egy nappal a határidő előtt.
• Címkézett ágak — egy címkével ellátott commit áthelyezése megsérti a szemantikus verziózás konvencióit.
• CI/CD hash-hez kötve — egyes telepítési rendszerek a build-eket a commit hash alapján azonosítják; a rebase megtöri a nyomon követést.

Gyakorlati munkafolyamat rebase-szel

A modern csapatokban leggyakrabban a rebase-orientált munkafolyamatot használják a GitHub Flow-val kombinálva. A folyamat így néz ki: a fejlesztő létrehoz egy feature-ágat a main-ből, dolgozik benne, időszakosan szinkronizál a git rebase main segítségével, és a pull request létrehozása előtt egy interaktív rebase-t végez a történet tisztításához.

A PR létrehozása után (ha új változtatásokat kell behúzni a main-ből) a szokásos git pull helyett git pull --rebase main használatos. Ez lehetővé teszi a változtatások behúzását anélkül, hogy felesleges merge-commit jönne létre. A --rebase jelzővel ellátott git pull egyenértékű a git fetch + git rebase-szel — a Git először betölti az új commit-okat, majd a helyi változtatásokat a tetejükre helyezi.

A Git lehetővé teszi a rebase beállítását alapértelmezett viselkedésként a pull számára: git config --global pull.rebase true. Ezen konfiguráció után a git pull mindig rebase-t hajt végre a merge helyett. Ha szokásos pull szükséges — a git pull --no-rebase használatos. Sok csapat az autostash-t is bekapcsolja: git config --global rebase.autoStash true — ez automatikusan elrejti a nem commit-elt változtatásokat a rebase előtt, és visszaállítja azokat utána.