Rebasing a folyamat mozgó vagy ötvözi egy sor kötelezettséget, hogy egy új bázis elkövetni. Az újraindítás a leghasznosabb, könnyen megjeleníthető a szolgáltatás elágazás munkafolyamat összefüggésében. Az általános folyamat a következőképpen jeleníthető meg:

tartalom szempontjából az újraszabályozás megváltoztatja az ág alapját egyikről a másikra, így úgy tűnik, mintha az ágat egy másik elkövetésből hozta volna létre., A GIT ezt belsőleg úgy valósítja meg, hogy új kötelezettségvállalásokat hoz létre, majd alkalmazza azokat a megadott bázisra. Nagyon fontos megérteni, hogy bár az ág ugyanúgy néz ki, teljesen új elkötelezettségekből áll.

használat

az újraindítás elsődleges oka a lineáris projekt előzményeinek fenntartása. Vegyünk például egy olyan helyzetet, amikor a mesterág előrehaladt, mióta elkezdtél dolgozni egy jellemző ágon., Szeretné, hogy a legújabb frissítéseket a master branch a funkció ág, de szeretné tartani a fióktelep története tiszta, így úgy tűnik, mintha már dolgozik ki a legújabb mester ág. Ez adja a későbbi előnye a tiszta egyesítése a funkció ág vissza a mester ág. Miért akarjuk fenntartani a “tiszta történelmet”? A tiszta történelem előnyei kézzelfoghatóvá válnak a GIT műveletek végrehajtásakor, hogy megvizsgálják a regresszió bevezetését. Egy valósabb forgatókönyv a következő lenne:

1. egy hibát azonosítanak a mesterágban., Egy olyan funkció, amely sikeresen működött, most megtört.
2. a fejlesztő a git log használatával vizsgálja a mesterág történetét a “tiszta előzmények” miatt a fejlesztő gyorsan meg tudja érteni a projekt történetét.
3. a fejlesztő nem tudja azonosítani, hogy a hibát a git log használatával vezették be, így a fejlesztő végrehajtja a git bisect.
4. mivel a git előzményei tiszták, git bisect van egy finomított sor elkötelezi magát, hogy összehasonlítsa a regresszió keresésekor., A fejlesztő gyorsan megtalálja azt a hibát, amely bevezette a hibát, és képes ennek megfelelően cselekedni.

Tudjon meg többet a git log and git bisect-ről az egyes Használati oldalakon.

két lehetősége van a funkció integrálására a fő ágba: közvetlenül egyesítés vagy újraindítás, majd összevonás. Az előbbi opció egy 3-utas egyesítést és egy merge commit-et eredményez, míg az utóbbi egy gyors előre egyesítést és egy tökéletesen lineáris előzményt eredményez. Az alábbi ábra azt mutatja be, hogy a főágra történő újraindítás hogyan könnyíti meg a gyors előre történő egyesítést.,

az Újraindítás gyakori módja az upstream változások integrálásának a helyi tárolóba. Húzás upstream változások Git merge eredményez felesleges merge elkövetni minden alkalommal, amikor szeretné látni, hogy a projekt előrehaladtával. Másrészt az újraindítás olyan, mintha azt mondanám: “a változásaimat arra szeretném alapozni, amit mindenki már megtett.”

ne rebase public history

ahogy már korábban tárgyaltuk újraírása történelem, soha nem kell rebase kötelezi, ha már tolta a nyilvános adattár., A rebase újakra cserélné a régit, és úgy nézne ki, mintha a projekt történetének ez a része hirtelen eltűnt volna.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive az, amikor a git rebase Elfogad egy -- i argumentumot. Ez az ” interaktív.”Argumentumok nélkül a parancs normál módban fut. Mindkét esetben tegyük fel, hogy létrehoztunk egy külön funkció ágat.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase normál módban automatikusan megteszi a kötelezettségvállalásokat a jelenlegi munkaágban, majd alkalmazza azokat az átadott ág fejére.

 git rebase 

Ez automatikusan átirányítja az aktuális ágat a – ra, amely bármilyen hivatkozási lehet (például egy azonosító, egy ág neve, egy címke vagy egy relatív hivatkozás a HEAD).

Runninggit rebasewith the-i flag begins an interactive rebasing session., Ahelyett, hogy vakon mozgatná az összes kötelezettséget az új bázisra, az interaktív Újraindítás lehetőséget ad arra, hogy megváltoztassa az egyéni kötelezettségvállalásokat a folyamat során. Ez lehetővé teszi, hogy tisztítsák meg a történelem eltávolításával, felosztása, megváltoztatásával egy meglévő sor kötelezettséget. Ez olyan, mint a Git commit --amend a szteroidokon.

 git rebase --interactive 

Ez az aktuális ágat a – re állítja vissza, de interaktív újraindítási munkamenetet használ. Ez megnyit egy szerkesztőt, ahol parancsokat adhat meg (az alábbiakban leírtak szerint) minden egyes elkövetéshez, amelyet újra kell indítani., Ezek a parancsok határozzák meg, hogy az egyes kötelezettségvállalások hogyan kerülnek át az új bázisra. Azt is átrendezheti a commit lista, hogy módosítsa a sorrendben a elkötelezi magát. Miután megadta a parancsokat az egyes commit-ekhez a rebase-ben,a Git elkezdi lejátszani a Rebase parancsok alkalmazását. Az újraírási szerkesztési parancsok a következők:

további rebase parancsok

az újraírási előzmények oldalon részletezett módon az újraszabályozás régebbi és több commit, elkötelezett fájl és több üzenet megváltoztatására használható., Bár ezek a leggyakoribb alkalmazások, a git rebase további parancsbeállításokkal is rendelkezik, amelyek hasznosak lehetnek összetettebb alkalmazásokban.

• git rebase -- d azt jelenti, lejátszás közben a commit kerül kidobásra a végső kombinált commit blokk.
• git rebase -- p elhagyja a commit, ahogy van. Nem módosítja a commit üzenetét vagy tartalmát, és továbbra is egyéni elkötelezettség lesz a fióktelepek történetében.
• git rebase -- x lejátszás közben végrehajtja a parancssori shell script minden megjelölt elkövetni., Hasznos példa lenne a codebase tesztcsomagjának futtatása konkrét elkötelezettségeken, amelyek segíthetnek a regressziók azonosításában egy rebase során.

Recap

Az interaktív újraindítás teljes ellenőrzést biztosít a projekt előzményeinek kinézete felett. Ez sok szabadságot biztosít a fejlesztőknek, mivel lehetővé teszi számukra, hogy “rendetlen” történelmet kövessenek el, miközben a kód írására összpontosítanak, majd menjenek vissza, és tisztítsák meg a tényt követően.

a legtöbb fejlesztő szeretne interaktív rebase-t használni a szolgáltatás ágának polírozásához, mielőtt a fő kódbázisba egyesítené., Ez ad nekik a lehetőséget, hogy a tök jelentéktelen vállalja, törlés elavult is, illetve győződjön meg róla, minden más a megrendelés véglegesítése előtt, hogy a “hivatalos” projekt történetében. Mindenki másnak, úgy fog kinézni, mintha az egész funkciót egy jól megtervezett elköteleződés egyetlen sorozatában fejlesztették ki.

az interaktív újjászületés valódi ereje a létrejövő mesterág történetében látható. Mindenki másnak, úgy néz ki, mint egy ragyogó fejlesztő, aki végre az új funkció a tökéletes mennyiségű elkötelezi magát az első alkalommal., Így lehet egy projekt előzményeit tisztán és értelmesen interaktívvá tenni.

konfigurációs beállítások

van néhány rebase tulajdonság, amelyet a git configsegítségével lehet beállítani. Ezek a Beállítások megváltoztatják agit rebase kimeneti megjelenést.

• rebase.stat: logikai érték, amely alapértelmezés szerint hamis. Az opció átkapcsolja a vizuális diffstat tartalom megjelenítését, amely megmutatja, mi változott az utolsó debase óta.

• rebase.missingCommitsCheck: több értékre állítható, amelyek megváltoztatják a rebase viselkedését a hiányzó elköteleződések körül.,/tr>
  

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Amikor a git rebase --onto üzemmód parancsot kitágul, hogy:

    git rebase --onto 

  A --onto parancs lehetővé teszi, hogy egy erősebb formája, vagy rebase, amely lehetővé teszi a múló konkrét bíró, hogy a tippeket a rebase.
  tegyük fel, hogy van egy példa repo ágakkal, mint:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB alapul featureA, azonban rájövünk featureB nem függ a változások featureA, és lehet csak elágazó le mester.

    git rebase --onto master featureA featureB 

  a ., master lesz a és featureB hivatkozás, amit HEAD a fog mutatni. Az eredmények ezután:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  A rebase

  veszélyeinek megértése egy figyelmeztetés, amelyet figyelembe kell venni, amikor a Git Rebase-val dolgozik, az egyesítési konfliktusok gyakoribbá válhatnak a rebase munkafolyamat során. Ez akkor fordul elő, ha van egy hosszú életű ága, amely eltévedt a mestertől., Előbb-utóbb lázadni akarsz a mester ellen, és abban az időben sok új kötelezettséget is tartalmazhat, amelyekkel a fiókteleped változásai ütközhetnek. Ez könnyen orvosolható azáltal, hogy gyakran visszautasítja fióktelepét a mester ellen, és gyakoribbá teszi a kötelezettségvállalásokat. A--continue és--abort parancssori argumentumok átadhatók agit rebase parancssori argumentumoknak a rebase előre vagy visszaállításához konfliktusok kezelése során.

  az interactive history rewritingtől egy komolyabb rebase caveat elvész., A rebase interaktív módban történő futtatása, valamint az olyan alparancsok végrehajtása, mint a squash vagy a drop, eltávolítja a kötelezettségvállalásokat a branche azonnali naplójából. Első pillantásra ez úgy tűnhet, mintha a kötelezi véglegesen eltűnt. A git reflog használatával ezek a kötelezettségvállalások visszaállíthatók, és a teljes újraindítás visszavonható. A git reflog használatával kapcsolatos további információkért keresse fel a GIT reflog dokumentációs oldalt.

  maga a Git Rebase nem komolyan veszélyes., Az igazi veszély eset akkor merül fel, amikor a végrehajtó történelem újraírása interaktív rebases kényszeríteni nyomja az eredményeket, hogy egy távoli ág, amely megosztja a többi felhasználó. Ez egy olyan minta, amelyet el kell kerülni, mivel képes felülírni más távoli felhasználók munkáját, amikor húzza.

  felépülés upstream rebase

  Ha egy másik felhasználó visszaállt, és erő tolta az ág, amit vállal, a git pull majd felülírja minden kötelezettséget már alapján ki, hogy az előző ág a csúcs, hogy volt erő tolta., Szerencsére a git reflog használatával megkaphatja a távoli ág naplóját. A távoli fióktelep naplójában talál egy ref-t, mielőtt visszaállították. Ezután újraindíthatja ágát a távoli ref ellen a--onto opcióval, amint azt az Advanced Rebase Application szakaszban fentebb tárgyaltuk.

  összefoglaló

  ebben a cikkben a git rebase felhasználást tárgyaltuk. Megvitattuk az alapvető és a fejlett felhasználási eseteket, valamint a fejlettebb példákat., Néhány kulcsfontosságú vitapont:

  • git rebase standard vs interactive modes
  • git rebase configuration options
  • git rebase — ra
  • git rebase lost commit