Hogyan használd a Git Rebase-t lépésről lépésre és anélkül, hogy elrontanád

Ha már egy ideje Gittel dolgozol a Visual Studio-ban , valószínűleg hallottál már olyanokat, hogy „csinálj egy újrabázisolást a pull request megnyitása előtt” vagy „ne végezz újrabázisolást távoli gépen”, és talán még mindig kicsit tanácstalan vagy, nem teljesen biztos benne, hogy mi is történik a történelemben. A Git újrabázisolása arról híres, hogy hatékony, de veszélyes is, és ez a tisztelet gyakran abból fakad, hogy nem teljesen értjük, mit is csinál a motorháztető alatt.

Ebben az útmutatóban nyugodtan lebontjuk, mi az újrabázisolás, miben különbözik az egyesítéstől, mikor érdemes újrabázisolást használni, és mikor a legjobb elkerülni , hogyan működik az interaktív újrabázisolás, milyen veszélyei vannak a történet felülírásának, és hogyan lehet helyreállítani a hibát. Mindent standard spanyol nyelven (Spanyolországból) magyarázunk el, gyakorlati példákkal és feltételezések nélkül.

Mi a Git újrabázisolása?

A Git rebase egy olyan parancs, amely lehetővé teszi, hogy egy sor commitot "áthelyezz" egy új bázisra a Git előzménygráfon belül. Ahelyett, hogy két ágat egyesítéssel egyesítenél, a rebase egy ág commitjait egyenként "újra alkalmazza" a történet egy másik pontjára, új commit azonosítókat generálva és egy tisztább, lineárisabb idővonalat hagyva maga után.

Képzeld el, hogy van egy master ágad , és az A committal kezdve létrehozol egy feature ágat . Ebben az ágban számos commitot hajtasz végre, miközben a változtatások a master ágban folytatódnak. Az újraalapozás lehetővé teszi, hogy ezt mondd a Gitnek: „fogd a feature commitjaimat, és írd át őket úgy, mintha közvetlenül a master ágban végrehajtottam volna őket ”, ami egy rendezettebb előzményt eredményez köztes összevonási commitok nélkül.

Ez a művelet azt jelenti, hogy a Git átírja az újraalapozott ág előzményeit . Ez nem csak vizuális átszervezés: az új commitok új hash-ekkel jönnek létre, és a régiekre már nem hivatkoznak (bár egy ideig a reflogban maradhatnak). Ezért mondják, hogy az újraalapozás egyszerre hatékony és érzékeny.

Az egyik módja annak, hogy megértsük, az, ha a következőképpen gondolkodunk róla: míg az egyesítés két munkasort köt össze egyetlen konvergenciaponttal, az újrabázisolás „emeli” az ágat, lemásolja a commitokat, és beilleszti azokat egy másik ágba, mintha mindig is onnan származnának. Az eredmény általában egy tisztább előzmény, de az ár megváltoztatja a változtatások tényleges sorrendjét.

Újraalapozás kontra egyesítés: ugyanaz a cél, különböző utak

A rebase használatának fő kontextusa az, amikor az egyik ágból származó változtatásokat egy másikba szeretnéd integrálni . A Git két lehetőséget kínál: az egyesítést és az újrabázisolást. Mindkettő végső soron ugyanarra a helyre helyezi a kódot, de a történetben hagyott nyomuk nagyon eltérő.

A `git merge` használatával az aktuális ágad beépíti a commitokat egy másik ágból, és egy extra merge commit generálódik (kivéve a gyors előretekerés eseteit). Ez megőrzi az eredeti commit előzményeket, de ha sok merge van, a commit gráf úgy nézhet ki, mint egy tányér spagetti. Az előnye, hogy nem írsz felül semmit ; egyszerűen hozzáfűzöd.

A `git rebase` használatával egy összevont commit létrehozása helyett a commitokat egy másik ág tetejére helyezed, mintha mindig is ott lettek volna. Az eredmény egy lineáris előzmény, ahol egyértelmű, hogy az egyes változtatások "mire" épültek. A hátránya, hogy a commit hash-ek módosulnak , és ha ezek a commitok már meg voltak osztva, az komolyan bonyolíthatja a távoli repositoryt és a kollégáidét.

Nagyobb csapatokban gyakori a két stratégia kombinálása: az újrabázisolást a helyi ágakon vagy az összevonás előtt alkalmazzák egy funkció előzményeinek kitisztítására, majd egy összevonással integrálják a fő ágba (néha gyorsítás nélkül), hogy megőrizzék az integrációs pont egyértelműségét.

A kulcs annak megértése, hogy sem az egyesítés, sem az újraalapozás nem eredendően „jobb”; ezek különböző eszközök. Az egyesítés biztonságosabb és átláthatóbb; az újraalapozás elegánsabb a történet szempontjából, de felelősséggel jár a commitok átírásakor.

A Git rebase alapvető használata

Az újrabázisolás leggyakoribb felhasználási esete, amikor egy funkcióágon dolgozol, és a legújabb változtatásokat szeretnéd áthozni a főágból (például a master vagy a develop) anélkül, hogy további egyesítési véglegesítést hoznál létre. A klasszikus munkafolyamat nagyjából így nézne ki:

Például a saját szakterületeden dolgozol. feature/login, és az ág A mester előrelépett új commitokkal a funkció megnyitása óta. A lineáris felzárkózáshoz a következőket kell tennie:

git checkout feature/login
git fetch origin
git rebase origin/master

Ezzel a paranccsal a Git kiveszi a feature/login könyvtárból a commitokat , és újraalkotja azokat az origin/master könyvtárban található legújabb commitra . Ha nincsenek ütközések, akkor egy olyan előzményt kapsz, amelyből úgy tűnik, hogy a módosítások mindig a master könyvtár legfrissebb verzióján történtek.

A célágból is át lehet építeni az alapértéket, például:

git checkout feature/login
git rebase master

Ez feltételezi, hogy a helyi master könyvtár naprakész. Az eredmény ugyanaz: a funkciócommitok felülíródnak a master könyvtárra . Mindkét esetben minden commit újrajátszásra kerül, és ha ütközések vannak, azokat egyenként bemutatja a rendszer, hogy megoldhasd őket.

Egy másik nagyon gyakori megközelítés egy olyan ág felülírása, amely eredetileg egy másik köztes ágon alapult. Például van egy jellemzőágad , amely egy másik ág alapjául szolgál . Ha ezután úgy döntesz, hogy ezt az ágat közvetlenül a fő ághoz kell kapcsolni a jellemző helyett, akkor a következőt használhatod:

git checkout branch
git rebase master

Ennek az az eredménye, hogy az ág "átugrik" a régi alapról (feature) az új alapra (master) , megtartva a módosításokat, de a commit gráf egy másik pontjára támaszkodva.

Ne rendezze át a nyilvános nyilvántartást

Az újraalapozás fő biztonsági figyelmeztetése egyértelmű: ne írjunk át olyan commitokat, amelyeket már távolról megosztottunk , és amelyekre mások alapozhatják a munkájukat. Ez különösen fontos az olyan ágakban, mint a master, a develop vagy bármilyen együttműködésen alapuló ág.

Amikor túllépsz egy ágon, és akkor git push -f o git push --force-with-leaseAmit mondasz, az az, hogy „az én verzióm felülírja a szerveren lévőt”. Ha valaki véglegesítette a távoli ágat a klónozás vagy a törlődés után, Ezek a véglegesítések elveszhetnek, vagy bonyolult eltéréseket generálhatnak. megjavítani.

Képzeljük el a következő forgatókönyvet: két ember klónoz egy repositoryt, mindketten a saját helyi águkon dolgoznak, ugyanazon a távoli ágon alapulva, és az egyikük úgy dönt, hogy újraalapozza és kikényszeríti a push-olást. A másik személy továbbra is a régi verzióval dolgozik. Amint megpróbálják letölteni vagy push-olni a módosításaikat, a Git észleli, hogy az alapjuk nem egyezik a távolival , és elkezdődnek a fejfájások.

Ezért általában ajánlott az újrabázisolást (rebase) használni a helyi ágakon vagy a még nem véglegesített funkcióágakon . Ha a véglegesített ágakat először ki kell törölni, tökéletes. Ha az ág már a távoli szerveren van, és mások dolgoznak rajta, akkor érdemes alaposan átgondolni, egyeztetni a csapattal, és ha úgy döntesz, hogy átírod, egyértelműen bejelenteni.

Az aranyszabály, amit gyakran ismételnek: ne bázisold át azokat a commitokat, amik nem kizárólag a tiéd . Ha te vagy az egyetlen, aki hozzányúlt ezekhez a commitokhoz, és tudod, mit csinálsz, akkor folytasd; ellenkező esetben jobb, ha egyesíted őket, vagy egy másik ágat nyitsz az átszervezéshez.

Standard Git újrabázisolás vs. interaktív Git újrabázisolás

Amikor újraalapozásról beszélünk, valójában két típusra gondolunk: a „normál” (nem interaktív) újraalapozásra és az interaktív újraalapozásra . Az első egyszerűen áthelyezi a commitokat egyik bázisról a másikra; a második lehetővé teszi a commitok szerkesztését, átrendezését, egyesítését vagy törlését a folyamat során.

A standard újrabázist például a következővel használod: git rebase master o git rebase origin/developItt a Git mechanikusan alkalmazza az ágad minden egyes commitját az új bázisra, és csak akkor áll meg, ha ütközések vannak, ekkor beavatkozol azok megoldása és a folytatás érdekében. git rebase --continue.

Az interaktív újrabázisozás az -i kapcsolóval engedélyezhető , jellemzően a commitok tartományát megadva az ágvégtől visszafelé. Például:

git rebase -i HEAD~5

Ez jelzi a Gitnek, hogy az utolsó öt committal szeretnél "játszani". A Githez konfigurált szövegszerkesztőd (alapértelmezés szerint általában vim vagy nano) megnyílik ezen commitok listájával, mindegyiket a ` pick` szó előzi meg . Itt a `pick` szót más utasításokkal helyettesítheted, hogy tetszés szerint átírd a történetét.

Ez az interaktív megközelítés arra szolgál, hogy egy sor commitot csiszoljon a megosztás előtt: kisebb változtatások egyesítése, üzenetek javítása, túl nagy commitok szétválasztása, vagy a távoli adattárba nem jutó commitok közvetlen eltávolítása.

További átszervezési parancsok az interaktív újraalapozásban

A megnyíló fájlban git rebase -i Valami ilyesmit fogsz látni:

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B

Az ötlet az, hogy a `pick` parancsot más parancsokkal helyettesítheted , hogy módosítsd, hogyan kezelje a rendszer az egyes commitokat az újrabázisolás során. A leggyakoribbak a következők:

• csákány (p)Használd a commitot úgy, ahogy van.
• átfogalmazás (r)Alkalmazd a commitot, de állítsd meg az üzenet módosítását.
• szerkesztés (e)Alkalmazd a commitot, majd állítsd le, hogy a tartalmát módosíthasd (például fájlokat adj hozzá vagy távolíts el) a következővel: git commit --amend.
• tök (ek): egyesíti ezt a commitot az előzővel, és lehetővé teszi az egyesített üzenet szerkesztését.
• javítás (f): ugyanaz, mint a squash, de elveti az üzenetet ebből a commitból, és megtartja az előzőből származót.
• csepp (d): eltávolítja ezt a commitot a történetből.

A fenti példában például összevonhatsz egy commitot, amely kijavít egy korábbit , áthelyezhetsz egyet feljebb, szétválaszthatsz egy nagyot, és kijavíthatsz egy elgépelést tartalmazó üzenetet. A szerkesztett fájl így nézhet ki:

pick 1fc6c95 Patch A
squash fa39187 something to add to patch A
pick 7b36971 something to move before patch B
pick 6b2481b Patch B
fixup c619268 A fix for Patch B
edit dd1475d something I want to split
reword 4ca2acc i cant' typ goods

Amikor mented és bezárod a szerkesztőt, a Git elkezdi sorban végrehajtani ezeket a parancsokat, és leáll, amikor beavatkozásra van szüksége (például erősítse meg az összenyomódásból eredő üzenetet(így a Szerkesztés funkcióval módosíthatod, vagy átírhatod az üzenetet a Rewordben). Minden egyes leállás megjelenik a terminál mit kell tenned, és emlékeztet arra, hogy amikor végeztél, futnod kell git rebase --continue.

Valamikor a Git megnyit egy fájlt, amelynek tartalma hasonló ehhez:

# This is a combination of two commits.
# The first commit's message is:
Patch A
# This is the 2nd commit message:
something to add to patch A

Az egyesített üzenetet változatlanul hagyhatja, vagy szerkesztheti, hogy jobban tükrözze az egyesített változást . Mentse el ismét, zárja be a szerkesztőt, és az újraalapozás addig folytatódik, amíg az összes parancs feldolgozása meg nem történt.

Interaktív újraalapozási folyamat összefoglalása

Egy interaktív újrabázisolás teljes folyamata jellemzően a következő mintát követi: először kiválasztod a commit tartományt (például HEAD~7 ), a Git megnyitja a commitok listáját tartalmazó fájlt, és szerkeszted a parancsokat és a sorok sorrendjét, hogy azok megfeleljenek az elérni kívánt előzményeknek. A mentés után a Git végigmegy az egyes utasításokon, szükség esetén megáll, és amikor hibák nélkül eléred a végét , az ágad teljesen átformált előzményekkel rendelkezik.

Minden alkalommal, amikor megáll, akár egy pillanatra is szerkesztés vagy egyesítési ütközés miatt módosíthatja a fájlokat, használhatja git add, csinálj egy git commit --amend Ha alkalmazható, és ha elégedett a feltételekkel, térjen vissza a git rebase --continueHa komoly hibát követsz el, vagy rájössz, hogy bajba keveredtél, mindig megszakíthatod a folyamatot. git rebase --abort hogy visszatérjen az előzési manőver megkezdése előtti állapotba.

Az interaktív újrabázisozás intelligens használatának tipikus eredménye egy logikusabb és olvashatóbb commit-sorozat: kevesebb zaj, kevesebb „elgépelés-javítás”, kevesebb ismétlődő commit és világosabb üzenetek. Ez sokkal könnyebbé teszi az előzmények áttekintését, a változtatások és azok okának megértését, valamint a jövőbeni felezést vagy hibakeresést.

Hasznos konfigurációs beállítások az újraalapozáshoz

A Git számos olyan konfigurációs opcióval rendelkezik, amelyek befolyásolják az újrabázisolás viselkedését, és rendszeres használat esetén megkönnyíthetik az életedet. Az egyik legismertebb az, amely alapértelmezés szerint lehetővé teszi a `git pull` számára az újrabázisolás használatát az egyesítés helyett :

git config --global pull.rebase true

Ezzel minden alkalommal, amikor ezt teszed git pullA Git megpróbálja felülírni a helyi módosításokat a távoli commitokkal ahelyett, hogy összevont commitot hozna létre. Ez egy kényelmes módja a karbantartásnak egy lineáris helytörténet anélkül, hogy mindig emlékezned kellene az írásra git pull --rebase.

Beállíthatod a szerkesztőt interaktív módra is, aliasokat konfigurálhatsz a hosszú rebase parancsokhoz, vagy aktiválhatsz olyan opciókat, mint az autostash bizonyos streamekben, bár ajánlott ezeket óvatosan használni, hogy ne vesszen szem elől, mit csinál a Git a nem véglegesített módosításokkal.

Speciális reorganizációs kérelem

Miután elsajátította az alapvető, interaktív átalapozást, elkezdheti használni fejlettebb forgatókönyvekben, például amikor több függő ága van, és azokat át szeretné alapozni anélkül, hogy túlzsúfolná a fő ágat. Például lehet egy kliens és egy szerver ága , amelyek egymástól függenek, és néhány módosítás után mindkettőt egy olyan fő ágra szeretné alapozni, amely már tartalmaz bizonyos átalapozásokat.

Ilyen helyzetben először felülírhatja a klienst a fő ágon, előretekerheti a fő ágat, majd felülírhatja a kiszolgálót az új fő ágon . Ez a fajta manőver biztosítja, hogy a történet egyértelműen megmutassa, hogy mely változtatások tartoznak az egyes ágakhoz, és milyen logikai sorrendben kerültek alkalmazásra, kereszt-egyesítések láncolata nélkül.

Az is lehetséges, hogy „átszervezünk egy átszervezést”: ha valaki felülírt egy ágat, és később a saját munkánkkal kell felülírnunk az átírt előzményeket, a Git lehetővé teszi ezt, bár ez növeli a konfliktusok és a zavar valószínűségét . Együttműködő környezetekben célszerű ezeket a műveleteket nagyon gondosan megtervezni, és szükség esetén előzménydiagramokat használni az eltévedés elkerülése érdekében.

Az átszervezés veszélyeinek megértése

Az újrabázisolás legnagyobb veszélye éppen az érdemében rejlik: átírja a történelmet . Ez nagyszerű arra, hogy a dolgok jól nézzenek ki, de kétélű fegyver, ha a commitok már publikálva vannak, vagy ha többen is támaszkodnak rájuk a napi munkájuk során.

Képzeld el, hogy klónozol egy repositoryt, és elkezdesz dolgozni a helyi ágadon, miközben a többi kolléga folyamatosan küld változtatásokat a fő ágnak. Ha egyikük úgy dönt, hogy újraalapozza a fő ágat, és kikényszeríti a push-olást, az alapként használt commitok eltűnhetnek a távoli repositoryból, vagy megváltozhatnak a hash-eik. A helyi nézőpontodból a te történeted egy történetet mesél el; a távoli repositoryból egy másikat.

Amikor pull vagy push parancsot próbálsz végrehajtani, a Git kénytelen lesz két inkompatibilis előzményt összeegyeztetni, és furcsa egyesítéseket hozhat létre, vagy elutasíthatja a push parancsot. Gyakran duplikált commitokat kapsz, ugyanazzal a tartalommal, de eltérő hash-ekkel, és egy még bonyolultabb előzményt, mint amivel eredetileg rendelkeztél.

Egy másik kockázat az, hogy információvesztés egy meggondolatlan erőltetett lökés miattHa a történet átírása közben valaki más jogos commitokat hajtott végre a távoli gépen, egy git push --force Egyszerűen felülírhatod ezeket a módosításokat, és eltüntetheted őket. Visszaállításuk sok időt és a reblogok ismeretét igényelheti, kivéve, ha túl sok idő telt el.

Mindezen okok miatt az egyensúly helyreállítását „csodálatos” eszköznek tekintik, de olyannak, amelyet körültekintően kell használni. Egyéni szinten lehetővé teszi a makulátlan teljesítmény fenntartását; csapatszinten, ha helytelenül használják, megzavarhatja a csapatmunkát és nehezen megoldható konfliktusokat teremthet.

Felépülés egy magasabb szintű átszervezésből

Ha egy újrabázisolás elfajul, az első teendőnk nem a pánik. A Git egy reflog nevű naplót vezet , amely egy ideig tárolja a referenciák (például a HEAD) korábbi pozícióit. Ez azt jelenti, hogy még ha felül is írtunk commitokat, továbbra is hozzáférhetünk azokhoz és visszaállíthatjuk az előző állapotot.

Egy rosszul sikerült előzési manőver kellős közepén a leggyorsabb teendő általában a következő:

git rebase --abort

Ezzel a Git megpróbál visszatérni pontosan oda, ahonnan az újrabázisolási műveletet indítottad, mintha soha nem is kezdted volna. Ez ideális például akkor, ha egy végtelen konfliktusláncban találod magad, és úgy döntesz, hogy nem érdemes ezen az úton folytatni.

Ha a probléma az, hogy már elvégezted az újraalapozást, sőt, még egy kényszerített tolást is végrehajtottál, a dolgok bonyolultabbá válnak. Lokálisan használhatod git reblog hogy megtaláld a commit hash-ét, ahol az újrabázisolás előtt voltál, és ha megvan, akkor csináld a következőt: git reset --hard eddig a pontig. Ha azonban felülírta a távirányítót, és más klónok már frissültek, A visszatéréshez az egész csapat összehangolása szükséges. és bizonyos esetekben elfogadják, hogy a mű egy része „elveszett” abban az értelemben, hogy már nem része a hivatalos történelemnek.

Amikor egy újraalapozási hiba több embert érint, a gyakorlati megoldás általában egy új kiindulópont egyeztetését jelenti egy ágon belül (például egy új ág létrehozását egy egészséges commitból), és a változtatások lekérését az érintett ágakból , akár kiválasztott elemek kiválasztásával, akár javítások alkalmazásával. Ez egy macera, de általában előnyösebb, mint megpróbálni "varázslatosan visszavonni" egy megosztott, már többször módosított előzményt.

Ütközésösszevonások az újrabázisban

Az újrabázisolás során fellépő egyesítési ütközések hasonlóan működnek, mint a normál egyesítés során, azzal a különbséggel, hogy commitról commitra jelennek meg . Minden alkalommal, amikor a Git megpróbál commitot alkalmazni, és azt észleli, hogy egy fájl ugyanazon töredéke inkompatibilis módon megváltozott az alapban, megjelöli az ütközést a fájlokban.

A fájlban olyan elválasztó karaktereket fogsz látni, mint például:

<<<<<<< HEAD
contenido de tu rama actual
=======
contenido de la rama rebasada
>>>>>>> updated_address

A <<<<<<<< HEAD és a ======= között az egyik verzió tartalma található, a ======= és a >>>>>>> között pedig a másik. A feladatod a fájl szerkesztése, csak a projekt szempontjából értelmes kombinációk megtartásával és a könyvjelzők eltávolításával.

Miután az összes érintett fájl tartalmát megoldotta, használja a következőt: git add <archivo> a konfliktusok megoldottként való megjelöléséhez. Ezután futtatod a git rebase --continue hogy a Git a sorozat következő commitjára léphessen. Ha olyan ütközésbe ütközik, amelyet nem érdemes megoldani az adott commit esetében, akkor olyan lehetőségei is vannak, mint például git rebase --skip kihagyni, bár ez azt jelenti, teljesen hagyd ki azt a commitot a keletkezett történelemnek.

Mivel az újrabázisolás egymás után hajtja végre a commitokat az olyan ágakban, amelyek sok változást és az alaptól való nagy eltéréseket tartalmaznak, ez unalmas lehet: minden egyes commit, amely ugyanazt az ütköző kódrészletet érinti, arra kényszerít, hogy javítsd azt. Ilyen esetekben egy normál összevonás vagy a változtatások átrendezése először az ütköző felület csökkentése érdekében hatékonyabb lehet.

Git újrabázisolás, push-force és push-force-with-lease

Amikor átírod egy ág előzményeit, és az ág egy távolihoz csatlakozik, a Git biztonsági ellenőrzéseibe ütközöl: ha a távolinak eltérő előzményei vannak, egy egyszerű git push El fogják utasítani. Ahhoz, hogy ezt a történetet lecseréld, erőltetett lökésre van szükséged.

Két gyakori változat létezik: git push --force y git push --force-with-leaseAz első kérdés nélkül felülír, míg a második egyfajta „biztonsági hálót” ad hozzá, hogy megakadályozza mások commitjainak felülbírálása. a --force-with-leaseA Git ellenőrzi, hogy a távoli kiszolgáló továbbra is a létrehozott commitra mutat-e; ha valaki megváltoztatta a szerveren lévő ágat, miközben a helyi előzményeket írtad át, a push kérés elutasításra kerül.

Képzeljük el azt a forgatókönyvet, amikor egy sor commitot adunk a távoli ághoz, és úgy döntünk, hogy az egyik (például a c2) helytelen. Lokálisan átírjuk, új commitokat generálunk (c3, c4), és ezeket szeretnénk megvalósítani. Ha senki más nem nyúlt az ághoz, akkor a `--force-with-lease` kapcsolóval végrehajtott push parancs gond nélkül frissíti a távoli ágat . Ha azonban valaki hozzáadta például a c5 commitot, miközben a módosításokat készítettük elő, ez a jelző megakadályozza, hogy véletlenül felülírjuk a munkáját.

Összefoglalva, ha már feltételezted, hogy egy újrabázis után erőltetni kell az elmozdulást, a szokásos megközelítés a következő: git push --force-with-lease hacsak nincs nagyon konkrét okod arra, hogy ezt akard felülír mindent a --forceEnnek ellenére tanácsos ezt közölni a csapattal, és összehangolni az időzítést a konfliktusok minimalizálása érdekében.

Újraalapozás, ágkontextusok és munkafolyamat

Az újrabázisolás megértésének egy másik érdekes módja, ha az ágakat olyan munkakörnyezetekként képzeljük el , amelyek megosztják a történet egy részét, de aztán külön utakon haladnak. Például, ha egy git-flow munkafolyamatot követünk, lehet egy fejlesztési águnk, amelyből funkcionális ágak jönnek létre (A1, A2 stb.).

Amikor az A1 kontextusban vagy, bármit is csinálsz ott, az nem befolyásolja a fejlesztést, amíg egyesítést vagy újraalapozást nem hajtasz végre. Olyan ez, mintha két párhuzamos idővonal lenne , amelyek közös eredettel rendelkeznek, de különböző változásokat halmoznak fel. Egyesítéssel összekapcsolod ezeket az idővonalakat, és a Git egy commitot rögzít, ahol konvergálnak; újraalapozással átszervezed az A1 idővonalat, hogy úgy tűnjön, mintha mindig is néhány lépéssel a fejlesztés előtt járt volna.

Ha fejlesztés közben Pepe a develop-on, Nacho pedig az A1-en dolgozik, eljön az idő, amikor a develop-nak új commitjai lesznek, és az A1-nek is új commitjai lesznek. Ha Nacho el akarja kerülni az összevonásos commitot az A1 develop-ba integrálásakor, a következőket teheti:

git checkout A1
git rebase develop

A Git a developból származó commitokat az A1-ből származók "alá" helyezi, átírva az A1 előzményeit úgy, hogy a módosítások a develop legújabb verzióján jelenjenek meg. Az előzményeket tekintve úgy tűnik, hogy Nacho mindig a develop legfrissebb állapotára támaszkodott , annak ellenére, hogy valós időben ez nem volt így.

Ez a fajta munkafolyamat nagyon kényelmes, ha egyedül dolgozol, vagy ha az A1 ágat még nem osztották meg. A probléma akkor merül fel, ha az A1 már a távoli szerveren van, és más csapattagok már feltöltötték. Ha Nacho az A1-et a fejlesztői ágra alapozza át, majd kikényszeríti a feltöltés funkciót, akkor megszakítja a távoli verzió és a mindenki mással rendelkező helyi verzió közötti kapcsolatot, arra kényszerítve őket, hogy egy olyan történettel szinkronizáljanak, amely már nem hasonlít a korábbihoz.

Visszapattanó és az ebből eredő konfliktusok csapatmunkában

Egy együttműködésen alapuló forgatókönyvben, mint amilyenben az imént is leírtuk, az újrabázisolás és az egyes személyek helyi adattárai közötti interakció kényes lehet. Amikor Nacho újrabázisolja az A1-et, lokálisan oldja fel a konfliktusokat, és elégedett az eredménnyel, végrehajt egy git push --force-with-leaseA távirányító most az új, átírt történelmet tükrözi.

Eközben Pepe továbbra is az A1 helyi példányát használja, ami még mindig az újraalapozás előtti verzió. Ha Pepe lekéri vagy megpróbálja beküldeni a változtatásokat, a Git észleli, hogy a története eltér a távolitól . A legjobb esetben vissza kell állítania a helyi ágat az új távoli HEAD ágra, és újra kell alkalmaznia a változtatásokat; a legrosszabb esetben elveszítheti a munkáját, ha nem vigyáz, és hard reset-et hajt végre mentés nélkül.

Ezért egy megosztott ág újraalapozásakor fontos, hogy egyértelműen értesítsük a csapat többi tagját, hogy explicit módon frissítsék a helyi águkat , például a következő használatával:

git fetch origin
git checkout A1
git reset --hard origin/A1

Az ilyen típusú műveleteknek kivételeknek kell lenniük, nem pedig szabálynak. A mindennapi használathoz általában a legjobb az újraalapozást a személyes jellemzőágakra korlátozni, és a megosztott ágakat (fejlesztés, master) egy összevonáson alapuló előzményekkel meghagyni, ami nem sérti senki helyi klónjait.

Az újrabázisolás során felmerülő konfliktusok tekintetében a folyamat mindig ugyanaz: a Git minden egyes konfliktust commitról commitra jelenít meg, te szerkeszted az érintett fájlokat, és a változtatásokat megoldottként jelölöd meg a következővel: git add és te folytatod git rebase --continueHa bármilyen oknál fogva a helyzet kicsúszik az irányítás alól, megszakíthatja és újragondolhatja a stratégiát.

Interaktív újraalapozás: szórakozás és rendrakás mindenkinek

Bár sok oktatóanyagban csak röviden említik, az interaktív visszatérítési mód az egyik legjobb eszköz a történet létrehozásához. tiszta, következetes és könnyen áttekinthető. a git rebase -i Egyetlen munkamenetben egyesíthetsz kisebb commitokat, javíthatsz üzeneteket, és feljebb vagy lejjebb mozgathatsz commitokat. El Tiempo, ossz fel egy nagy commitot több logikusabb részre, vagy egyszerűen töröld az értelmetlen változtatásokat.

Például, ha az utolsó hét commitot szeretnéd finomítani, akkor a következőt kell futtatnod:

git rebase --interactive HEAD~7

A szerkesztőd megnyílik a hét commit listájával. Innen eldöntheted, hogy egy adott, kisebb javításokat tartalmazó commitot egyesíts-e a funkcionalitás eredeti commitjával ( squash vagy fixup használatával ), hogy egy másik commitot áthelyezz-e a "Patch B" elé, hogy egy harmadik commitot kettéválassz-e az edit paranccsal , vagy hogy egy elgépeléseket tartalmazó üzenetet javíts-e a reword paranccsal.

A nagyszerű az egészben, hogy mindez a munka elkészül. mielőtt megosztaná a változtatásokat a világ többi részével, így ami a távoli csapathoz eljut, az már viszonylag tiszta múlttal rendelkezik. Ez nemcsak jobban néz ki, hanem megkönnyíti egy másik fejlesztő számára a commitok áttekintését, egy pillantással megérteni, hogy ki mit tesz hozzá, és szükség esetén olyan eszközöket használni, mint a git bisect hogy megtaláljuk a pontos pontot, ahol egy hiba megjelent.

Azonban érdemes megjegyezni a régi szabályt: bármi, amit az interaktív újrabázisolással csinálsz, átírja a commit hasheket. Mértékkel használd azokon az ágakon, amelyek csak a gépeden léteznek , és rendkívül óvatosan azokon az ágakon, amelyeket már migráltak egy távoli szerverre.

Röviden, a rebase (és különösen annak interaktív módja) egyfajta "előzményszerkesztő" a Git számára. Helyes használat esetén lehetővé teszi egy nagyon olvasható és professzionális előzményekkel rendelkező repository fenntartását; helytelen használat esetén zavart és fejfájást okozhat, különösen akkor, ha már megosztott ágakat kever, és koordináció nélküli push-okat kényszerít ki.

Ennek a parancsnak az elsajátítása időbe telik, de ha pontosan megérted, hogy mit csinál a commitjaiddal, kulcsfontosságú eszközzé válik az ágakkal való munkában, a történetek tisztán tartásában és a zökkenőmentes együttműködésben bármilyen méretű projekten.