Ha hasonló helyzetben van, és nem tudja milyen változás megtörte a kódot vagy WHO a sok közreműködő közül birtokolja ez hiba / szolgáltatás , akkor a git bisect a kiút. Tehát ebben a git bisect cikkben megtudhatja, hogyangit kétfelé’Parancs jön mentés a hibát bemutató első rossz elkötelezettség észlelésében a bináris keresési algoritmus segítségével.
A cikk témái a következők:
Miért érdemes használni a git bisectet?
Kétségtelen az a tény, hogy hajlamos vagy számos kötelezettségvállalást létrehozni minden kisebb változás esetén . Ilyen esetekben a kód hibakeresése unalmas feladattá válik, mivel manuálisan kell visszamennie a projekt pillanatkép minden egyes verziójához, hogy tesztelje a működő kódot és észlelje a hibát. Most ez még több lesz összetett amikor más munkája van, hogy ellenőrizzék vezető pont nélkül, akkor is, ha felkérik mindegyiket, hogy tisztítsák meg saját hibáikat, az sem hangzik nagyon megvalósíthatónak.
Útközben számos „szolgáltatás” (vagy gyorsjavítás) ágat is létrehozhat és elvethet a folyamat során, és végül időt és erőfeszítést pazarol, miközben eltér a fő fejlesztési vonaltól.
Tehát az ilyen esetek elkerülése érdekében használhatja agit kétfeléparancs a rossz projekt revízió (vagy pillanatkép) megkeresésére, és végül agit visszaparancs.
Hogyan keres a „git bisect”?
Ez a parancs kettészeli (megosztja) a történelmét a jó és a rossz elkövetni hatótávolság. Ez rámutat jelenlegi projekt állapot a középkategóriás elkövetni pillanatkép. Ezután a git bisect parancs áthalad minden elkötelezett azonosító e tartomány között miközben szüneteltetve minden pillanatképnél, hogy lehetővé tegye tesztelje a kódot . Ha a hiba létezik, akkor deklarálja az elkötelezettséget rossz, ha nem úgy jó hacsak a keresés nem ér véget.
Szintaxis
git kétfelé
A git bisect jobb megértése érdekében hozzunk létre egy olyan projektet, amely kidolgozza az autóban használható egyszerű navigációs alkalmazás kódját.
A projekt kezdeti beállítása
Ha olyan projektet szeretne létrehozni, amely kifejleszti az autóban használt egyszerű navigációs alkalmazás kódját, kövesse az alábbi lépéseket:
1. lépés: Hozzon létre egy új könyvtárat a $ HOME mappában:
cd $ HOME mkdir my_nav_app
2. lépés: Navigáljon az új könyvtárba:
hogyan kell használni a swing java-t
cd $ my_nav_app
3. lépés: Klónozva töltse le a projektet a GitHub oldalamról:
git klón https://github.com/divyabhushan/my_nav_app.git
Most pedig értsük meg a projekt könyvtárakat és a fájlok elrendezését, a parancs által kinyomtatott módon:ls -lTR
Ezután nézzük meg a projekttörténeti naplót, hogy megtekinthessem azokat a kötelezettségeket, amelyeket e kód létrehozása érdekében tettem.
Például egy egyszerű git naplóparancs részletesen kinyomtatja az előzményeket, azonban szeretem szépen formázni és testre szabni az előzményeket. Ezáltal engedjük meg álnév beállítása - ’hiszt’ használni a git alias parancs az alábbiak szerint:
git alias.hist 'log --pretty = format:'% C (sárga)% h% Creset% ad | % C (zöld)% s% Creset% C (piros)% d% Creset% C (kék) [% an] '--graph --dekoráció --dátum = rövid'
Most ezt a hibajavítási funkciót külön ágban fogom végrehajtani, hogy ne zavarjam a „master” ág fő fejlesztését. Ehhez kövesse az alábbi parancsokat:
- Hozz létre „dev” ágat: [mester] $
git ág dev - Váltás a „dev” ágra: $
git pénztár dev - Sorolja fel az előzmények naplóit: [dev] $
menj hist[Megjegyzés: az itt használt ‘alias’ parancs]
Továbbá kiemeltem az utolsó ismert jó elkötelezettséget, amelyről tudom, hogy a szkriptem jól működött a várt tesztesetek eredményeivel, ez az elkövetési pillanatkép megjelölt mint v1.0.
Tehát most, hogy tudjuk az utolsó jó elkötelezettségünket, folytassuk a „git bisect” című cikkben, és teszteljük az alkalmazást.
Tesztelje az alkalmazást
Futtassa a szkriptet - $ néven./scripts/myApplication.sh[először tesztelek]
Nyilvánvaló, hogy a jelenlegi projektállapotom van hiba , és nem vagyok biztos abban, hogy melyik elkötelezettségemben milyen változtatást hajtottam végre, amely bevezette ezt a változást. Tehát, ebben a cikkben a git bisectről, nézzük meg, hogyan lehet azonosítani a rossz elkövetést.
A rossz elkövetés azonosítása
A rossz elkövetés ellenőrzésének megkezdéséhez kövesse az alábbi lépéseket:
- Indítsa el a bisect parancsot :
git bisect start - Említse meg a rossz elkövetési azonosítót:
git kettéosztja a rossz FEJETvagygit bisect c5b3ca8 - Említse meg az utoljára ismert-jó-elkötelezett azonosítót:
git bisect jó v1.0vagygit bisect 93859d8
Ez nagyjából félúton kettévágja az elkövetési előzményeket a jó és a rossz elkötelezettségek között, amelyek eljutnak az elkövetési azonosítóig: f61a7e8
Ennélfogva a parancs megvizsgálta a projekt verzióját, mint amilyen ebben az elkötelezett azonosítóban volt. Most menjünk előre, és teszteljük újra az alkalmazást.
Parancs az alkalmazás futtatásához : $./scripts/myApplication.sh[tesztelés másodszor]
Az alkalmazás óta telt el ebben az elkötelezettségben ez az elkötelezettség biztosan nem a rossz elkötelezettség. Tehát ezután a bisect paranccsal ugyanazt kell megadnia, mint - $git bisect jó
Ez tovább szűkíti a keresési eredményt a tartomány első felére, az ábra szerint -
Teszteld újra az alkalmazást - Parancs: $./scripts/myApplication.sh[harmadszor tesztelek]
Tehát, mivel a fenti hibát látjuk, ez rossz elkövetés.
Tudassa a bisect paranccsal, futtassa a $ parancsotgit bisect rossz
Ez tovább szűkíti a keresést és eljut az utolsó kék körbevett középső változatig: a6ac769
Tehát utoljára tesztelem az alkalmazásomat ugyanazzal a paranccsal: $./scripts/myApplication.sh[tesztelés negyedik alkalommal]
Most, hogy az alkalmazás ismét kudarcot vallott, még mindig rossz elkötelezettség. Tehát futtassuk a következő parancsot:
Futtassa a parancsot: git bisect rossz
Rossz elkövetés található
Ezzel lezárul az egyetlen hátralévő kötelezettségvállalás, amely rossz
Tehát tudod, hogy itt tört el a kód. Mi a következő?
Értse meg, hogy melyik fájlban volt a hiba
Ebben az esetben a kimenet minimális információt nyújt a elkövetni id , szerző neve , és a szerzői dátum együtt a üzenetet elkövetni és a pálya hogy módosult.
Ha további hibakeresést szeretne, akkor meg kell olvas az id objektum végrehajtása .
Parancs: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
c ++ névtér példa
Ez elolvassa a kötelezettség objektumot, és kinyomtatja a naplóüzenetet és a szöveges diff.
Használhatja a „git blame” parancsot annak elemzésére is, hogy az egyes sorokat melyik szerző változtatta meg, és melyik elkötelezettségben, futtassa a parancsot:git hibás kód / develop_nav.sh
Állítsa le a keresést
A keresés leállításához használja a következő parancsot:
Parancs: git bisect reset
Így a félbevágási folyamat leáll, és visszatér az ághoz, ahonnan a keresést indította. Most a következő lépés a kód javítása vagy hibakeresése.
Hogyan lehet kijavítani / hibakeresni a kódot?
Nos, van néhány megoldás, amellyel kijavíthatná a projekt aktuális állapotát, miután azonosította azt az elkötelezettséget, amely elsősorban a hibát hozta.
Ha azonban megváltoztatja a megosztott adattár a legjobb visszaszáll a változás a ’ git vissza ’Parancs.
Feladat: Állítsa vissza az említett rossz elkövetés által végrehajtott változtatásokat
Parancs: git revert a6ac769
Ennek eredményeként az elkötelezettség által végrehajtott változtatások visszaállítása 2 dolgot tett:
- Törölte az utolsó 3 hozzáadott sort (zöld színnel jelölve), és a törölt sort (piros színnel jelezve) visszaadta. (a6ac769 fordítottja)
- Létrehozott egy extra elkötelezettséget az üzenet visszaállításával
„A Visszaállítás parancs megkönnyíti az eredeti kötelezettségvállalásból visszaállított változás nyomon követését is.”
Használja a 'előadás' parancs újra az objektum azonosítójának elolvasásához, például
Parancs: git show 801f029
Most megy előre, és tesztelje az alkalmazást. Megfelelően fog végrehajtani.
Parancs: $./scripts/myApplication.sh
Ezzel szemben, ha el akarja távolítani a rossz elkötelezettséget az előzményekből:
Használhatja a
git reset„Parancs a--kemény”Opciót (bár megosztott adattárban nem ajánlott).Nézze meg egy fájl korábbi verzióját a ‘
git pénztár’Parancs a’-' választási lehetőség.
Meg kell jegyeznünk, hogy ez csak addig változtat a helyi adattárban, amíg át nem helyezi a módosításokat egy távoli adattárba. Mivel néhány változás új kötelezettség objektum azonosítót hoz létre, mint a fenti esetünkben, ilyenkor a távoli adattár normál leküldését elutasítják, mivel az előzmények eltérnek egymástól. A „ git push ’Parancs a’--Kényszerítés' választási lehetőség.
Frissítse a „master” ágat
Míg javítottam a hibát a „dev” ágamon, most ezt a változást egyesíthettem a „master” ággal is-
- váltás „master” -re, parancs:
git checkout master - húzza a legújabb frissítéseket az „origin / master” -ről a „master” -re, parancs:
git pull eredet - egyesíti a „dev” változásokat, parancs:
git merge óriás
Az összevonás azonban konfliktusokat okozhat, ha a távoli adattárból több végrehajtás érkezik. Oldja meg az ütközéseket, és folytassa az egyesítéssel.
Végül tolja csak a stabil „master” ágat, amelyet a távoli adattárhoz köt, miközben piszkos munkáját (hibát, funkciókat, fejlesztéseket) csak azokon a funkciós ágaknál végzi el, mint például a „dev” ebben a példában.
Sőt, a legjobb, ha logikusat alkalmazunk elágazási stratégia a git munkafolyamatának ésszerűsítése és biztosítása érdekében.
Összefoglalva: a „git bisect” egy praktikus és hasznos parancs, amely gyorsan megtörténik azonosítani az elkövetni id hogy bemutatott nak nek hiba a futó kódban egy kiterjedt bináris keresés logikusan osztva az elkötelezett naplók félúton a jó és rossz elkövetni hatótávolság . Befejezésül megtanultad érzékeli a hibás elkövetés és visszaszáll az általa végrehajtott változás.
Ezenkívül a „jó” és a „rossz” alparancsokhoz olyan kifejezéseket is használhat, mint új és régi, hogy leírja a revízió állapotát. A parancsot többször is futtathatja különböző alparancsok és revíziós / véglegesítési azonosítók átadásával, hogy azonosítsa a különböző véglegesítési (she-1) azonosítókat. Alternatív megoldásként egy automatizált tesztfájl is futtatható a törött kód felépítéséhez ezzel a paranccsal. Ezenkívül futtatással keresse meg a parancs részletes leírásátgit bisect --helpa terminálon. Szóval, emberek ezzel véget értünk a Git Bisectről szóló cikknek.
A DevOps célja jobb minőségű szoftverek gyorsabb és megbízhatóbb létrehozása, miközben nagyobb kommunikációt és együttműködést hív meg a csapatok között. Ha érdekli ez a cikk, c a fenébe az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Az Edureka DevOps tanúsító tanfolyam segít a tanulóknak megérteni, mi a DevOps, és szert kell szerezni a különféle DevOps folyamatok és eszközök, például a Báb, a Jenkins, a Nagios, az Ansible, a Chef, a Saltstack és a GIT számára az SDLC több lépésének automatizálásához.
Van egy kérdésünk? Kérjük, említse meg a „Git Bisect” cikk megjegyzés-szakaszában, és azonnal kapcsolatba lépünk Önnel.