Az interaktív rebase-t néha a Git “svájci bicskájának” nevezik – mert annyi különböző eszközt tartalmaz, annyi különböző felhasználási esetre! Van azonban egy fő, átfogó felhasználási eset: a helyi commit-előzmények tisztítása.

A “helyi” szót ne feledjük: csak a saját, helyi commit-előzmények tisztítására használjuk, például mielőtt az egyik feature-águnkat integráljuk egy csapatágba. Ezzel szemben NEM használható olyan commit-előzményekre, amelyek már el lettek tolva és megosztva egy távoli tárolóhelyen. Az interaktív rebase egyike azoknak az eszközöknek, amelyek “átírják” a Git előzményeit – és ezt nem szabad olyan commitokon elvégezni, amelyeket már megosztottak másokkal.

Amivel ez a kis figyelmeztető üzenet elkerült az útból, nézzünk néhány gyakorlati példát!

Megjegyzés: az ebben a bejegyzésben szereplő forgatókönyvek és munkafolyamatok könnyebb szemléltetése érdekében néhány képernyőképen a “Tower” Git asztali GUI-t használtam.

Régi commit üzenet javítása

Máskor észreveszel egy elírást egy régi commit üzenetben – vagy elfelejtettél megemlíteni valamit a leírásban, ami figyelemre méltó. Ha a legutolsó commitról lenne szó, akkor egyszerűen használhattuk volna a git commit parancs --amend opcióját. De a régebbi commitok esetében az interaktív rebase-t kell használnod, hogy utólag módosítsd őket.

Itt egy példa egy szörnyen rosszul sikerült commit üzenetre, amit ki akarunk javítani:

Egy rossz commit üzenet, amit ki kell javítani

Az első lépés minden interaktív rebase munkamenetben, hogy meghatározzuk, a commit history mely részét akarjuk manipulálni. Hogy ismét a fenti példát vegyük: ahhoz, hogy ezt a rossz commitot megváltoztassuk, a munkamenetet a szülő commitjánál kell kezdenünk.

Interaktív rebase munkamenetünk indítása

Ezt a kezdő commit hash-ját most már be tudjuk táplálni az interaktív rebase parancsba:

$ git rebase -i 0023cddd

Ezután megnyílik egy szerkesztőablak, amely az imént manipulációra kiválasztott commitok listáját tartalmazza. És ne lepődj meg, mert ezek fordított sorrendben vannak: egy interaktív rebase munkamenetben a Git újra alkalmazza a régi commitokat, elemről elemre – ami azt jelenti, hogy a sorrend megfordítása a Git szempontjából helyes.

Editor ablak a kiválasztott commitokkal

Egy másik fontos dolog, amit ezzel a editor ablakkal kapcsolatban meg kell jegyezni: a tényleges manipulációkat nem itt végzed el! Illetve ebben a konkrét példában NEM itt mész előre és változtatod meg a commit üzenetet. Ehelyett csak a módosítani kívánt commitot jelölöd meg egy action kulcsszóval. A mi esetünkben, mivel egy commit üzenetét akarjuk megváltoztatni, a “reword” szóval jelöljük a sort. Ha ezután elmenti és bezárja ezt a szerkesztőablakot, egy új ablak nyílik meg, amely a régi commit üzenetét tartalmazza. Itt az ideje, hogy végre elvégezzük a változtatásokat:

Egyszer végre elvégezhetjük a változtatásainkat

A mentés és az ismételt bezárás után az interaktív rebase munkamenet befejeződött, és a régi commit üzenetünket kijavítottuk!

Minden commit egybefoglalása

Az interaktív rebase másik felhasználási esete, amikor több régi commitot szeretnénk egybefoglalni. Bár természetesen itt is érvényes a verziókezelés aranyszabálya: a legtöbb helyzetben előnyös több és kisebb commitot létrehozni néhány nagy helyett. Azonban mint mindenben, itt is előfordulhat, hogy túlzásba vittük a dolgot, és most két vagy több régi commitot szeretnénk egybeolvasztani.

Konkrét példával élve, tegyük fel, hogy a következő kiválasztott commitokat szeretnénk egyetlen commitba egyesíteni:

Egyszerre több commitot egyesítsünk

Az első esethez hasonlóan az interaktív rebase munkamenetet legalább annak a commitnak a szülő commitjánál kezdjük, amelyet manipulálni szeretnénk.

$ git rebase -i 2b504bee

Újra megnyílik egy szerkesztőablak, amely felsorolja a commit-történetünk azon részét, amelyet manipulálni szeretnénk:

Sorok jelölése “squash”

A műveleti kulcsszó, amelyet itt használni fogunk, a “squash”. És csak egy fontos információt kell tudnod a squash-ről, hogy használni tudd: a “squash” kulcsszóval megjelölt sort összekapcsoljuk a közvetlenül felette lévő sorral. Ezért, ahogy a fenti képernyőképemen is láthatod, a 2. sort “squash”-sel jelöltem, hogy egyesítsem az 1. sorral.

Menthetjük és bezárhatjuk a szerkesztőablakot, majd ismét figyeljük, és egy új ablak jelenik meg: most arra kérnek minket, hogy adjunk meg egy commit üzenetet az új commithoz, amely a két régi commit egyesítésekor jön létre.

Új üzenet megadása az új, összenyomott commithoz

A szerkesztőablak mentése és bezárása után látni fogjuk, hogy egy új commit jött létre, amely tartalmazza mindkét régi commit változáskészletét. Voila!

Hiba javítása

Az interaktív újraszerkesztés másik felhasználási esete az, amikor hibát találsz az egyik korábbi commitodban. És nem számít, hogy pontosan mit rontottál el: elfelejtettél hozzáadni egy bizonyos változtatást, törölnöd kellett volna egy fájlt, vagy egyszerűen csak egy elírást vezettél be…

A természetes tendencia ilyen helyzetben az, hogy egyszerűen létrehozol egy új commitot, ami kijavítja a hibát. Másrészt viszont ez összezavarja a commit-előzményeinket: egy eredeti commit készítése, majd egy “sebtapasz” commit hozzáadása csak azért, hogy kijavítsunk néhány hibát… ez egy rendetlen munkamódszer. A commit history hamarosan nehezen áttekinthetővé válik, mert tele lesz ezekkel a kis “gyorsjavító commitokkal”!

Ez az a pont, ahol a “fixup”, az interaktív rebase egyik eszköze nagyon jól jön. A fixup fogja ezt a “quick fix” commitot, alkalmazza a módosításait az eredeti commitra (ezáltal kijavítja azt), majd megszabadul a sebtapasz committól:

Hogyan működik a “fixup”

Miután végeztünk, úgy néz ki, mintha soha nem is lett volna probléma az eredeti commitunkkal! Tehát menjünk végig ezen egy gyakorlati példán.

Az első lépés az, hogy megteszünk mindent, ami szükséges a probléma kijavításához: ez jelentheti egy új fájl hozzáadását, a meglévők módosítását, az elavult fájlok törlését… “csak” elő kell állítani azokat a változtatásokat, amelyek kijavítják a hibát.

A következő lépés ezeknek a változtatásoknak a commitolása a tárolóba – de egy kis extrával: a commitoláskor használjuk a --fixup flaget, és közöljük a Git-tel a hibás commitunk commit hash-ját:

$ git add corrections.txt$ git commit --fixup 2b504bee

Ha most megnézzük a commit history-t, látni fogjuk, hogy egy elég közönséges kinézetű commit jött létre – valószínűleg nem az a varázslat és tűzijáték, amire számítottunk. De ha közelebbről megnézed, látni fogod, hogy valami történik: az új commit automatikusan a “fixup !” és a rossz commitunk commit-témája elé került.

Az eredeti commit és a fix commit

A harmadik lépés most az interaktív rebase munkamenet elindítása. Ismét a rossz commitunk szülőjét választjuk kiindulópontnak…

$ git rebase -i 0023cddd --autosquash

… és a titkos szósz második részeként a --autosquash flaget használjuk. Ez az opció gondoskodik arról, hogy a most megnyitott szerkesztőablakban ne kelljen semmit sem tennünk. Nézzük meg közelebbről a helyzetet:

A javító commitunk “fixup”-ként van megjelölve és a megfelelő pozícióba rendezve

Láthatjuk, hogy a Git automatikusan két dolgot tett helyettünk:

1. A javító commitunkat “fixup”-ként jelölte meg.”
2. Újrarendezte a sorokat, hogy a band-aid commitunk közvetlenül a rossz commitunk alatt jelenjen meg. Ez azért van így, mert a fixup pontosan úgy működik, mint a squash, azaz a fenti sorral kombinálódik.

Más szóval: nincs más dolgunk, mint menteni és bezárni a szerkesztőablakot.

Vessünk még egy pillantást a commit előzményekre:

A happy end!

Nem csak az eredetileg rossz commitunk tartalmazza most már a band-aid commitunk módosításait. De ráadásul a csúnya band-aid commit eltűnt a commit history-ból! Minden szép és tiszta, mintha soha nem is lett volna probléma!

Fedezd fel az interaktív rebase erejét

Az interaktív rebase-nek rengeteg felhasználási területe van – és a legtöbbjük a “hibák kijavítása” részlegben. Ha áttekintést szeretnél kapni más hasznos dolgokról, ajánlom az ingyenes “First Aid Kit for Git”-et: ez egy rövid videókból álló gyűjtemény (epizódonként 2-3 perc), amely segít megtanulni a hibák visszafordítását az interaktív rebase és más Git-eszközök használatával.

Szerkesztő megjegyzése: éppen ennek a bejegyzésnek az átnézésekor kellett használnom az interaktív rebase-t! Az egyik commitom egy 1 MB-nál nagyobb méretű képet tartalmazott, ami a GitLab weboldal projekt szabályaiba ütközik. Vissza kellett mennem és kijavítanom ezt a commitot, hogy helyette egy megfelelő méretű képet tartalmazzon. Köszönöm a leckét, univerzum! 😁

Még több Git tipp és trükk

• 15 Git tipp a munkafolyamatok javításához
• How Git Partial Clone lets you fetch only the large file you need
• Git happens! 6 gyakori Git hiba és hogyan javítsuk ki őket

A vendégszerzőről

Tobias Günther a Tower vezérigazgatója, a népszerű Git asztali kliens, amely világszerte több mint 100.000 fejlesztőnek segít abban, hogy a Git segítségével produktívabbak legyenek.

Cover image by David Taljat on Pexels

.