Om du befinner dig i en liknande situation och inte vet vilken förändring bröt koden eller WHO av många bidragsgivare äger detta bugg / funktion , då är git bisect din väg ut. Så, i den här artikeln om git bisect lär du dig hurgit halva'Kommando kommer till räddning för att upptäcka det första dåliga åtagandet som introducerar felet med hjälp av den binära sökalgoritmen.
Ämnen som tas upp i denna artikel är följande:
hur man använder swing java
Varför använda git bisect?
Det råder ingen tvekan om att du tenderar att skapa ett antal åtaganden för varje mindre förändring i . I ett sådant scenario blir felsökning av koden en tråkig uppgift, eftersom du måste manuellt gå tillbaka i tiden till varje enskild version av projektets ögonblicksbild för att testa arbetskoden och upptäcka felet. Nu blir det ännu mer komplex när du har andras arbete att inspektera utan en ledningspunkt, låter inte heller att begära var och en att städa upp sina egna misstag.
Längs vägen kan du också skapa och kasta ett antal 'funktions' -grenar (eller snabbkorrigeringar) under processen och sluta slösa tid och ansträngning medan du avviker från huvudlinjen för utveckling.
Så, för att undvika sådana scenarier kan du användagit halvakommando för att hitta den dåliga projektrevisionen (eller ögonblicksbilden) och så småningom fixa den medgit återgåkommando.
Hur söker 'git bisect'?
Detta kommando halvor (delar upp din historia mellan Bra och den dålig begå räckvidd. Det pekar din nuvarande projekt stat till en mellanklass begå ögonblicksbild. Kommandot git bisect går sedan igenom varje begå id mellan detta intervall medan pausar vid varje ögonblicksbild så att du kan testa koden . Om felet existerar förklarar du åtagandet som dålig, om inte som Bra såvida inte sökningen avslutas.
Syntax
git halva
För att förstå git-bisect bättre, låt oss skapa ett projekt som utvecklar koden för en enkel navigationsapp som ska användas i en bil.
Första projektinstallationen
För att skapa ett projekt som utvecklar koden för en enkel navigationsapp som ska användas i en bil kan du följa stegen nedan:
Steg 1: Skapa en ny katalog i din $ HOME-mapp:
cd $ HEMMA mkdir my_nav_app
Steg 2: Navigera till den nya katalogen:
cd $ my_nav_app
Steg 3: Klon för att ladda ner projektet från min GitHub-sida:
git-klon https://github.com/divyabhushan/my_nav_app.git
Låt oss nu förstå projektkatalogerna och fillayouten, som skrivs ut av kommandot:ls -lTR
Låt oss sedan se projekthistorikjournalen för att se de åtaganden jag gjorde för att generera denna kod-
Till exempel skriver ett enkelt git log-kommando ut historiken i detalj, men jag gillar att formatera och anpassa historiken. Låt oss därmed ange ett aliasnamn - 'hist' använda git alias kommando som visas nedan:
git alias.hist 'log --pretty = format:'% C (gul)% h% Creset% ad | % C (grön)% s% Creset% C (röd)% d% Creset% C (blå) [% an] '- graf - dekorera - datum = kort'
Nu ska jag utföra den här buggfixfunktionen i en separat gren för att inte störa huvudutvecklingen på 'master' -grenen. För att göra det, följ nedanstående uppsättning kommandon:
- Skapa filial 'dev': [master] $
git branch dev - Byt till gren 'dev': $
git checkout dev - Lista historikloggarna: [dev] $
gå hist[Obs: 'alias' -kommando som används här]
Vidare har jag markerat det senast kända bra engagemanget som jag vet i vilket mitt manus fungerade bra med förväntade testfallresultat. taggade som v1.0.
Så nu när vi känner till vårt senaste goda engagemang, låt oss gå vidare i den här artikeln om 'git bisect' och testa applikationen.
Testa ansökan
Kör skriptet som - $./scripts/myApplication.sh[testar första gången]
Det är uppenbart att mitt nuvarande projekt är i fel , och jag är inte säker på vilken förändring jag gjorde i vilket åtagande som införde denna förändring. Så nästa i den här artikeln om git bisect, låt oss se hur man identifierar det dåliga engagemanget.
Identifiering av det dåliga åtagandet
För att börja inspektera om det dåliga åtagandet följer du stegen nedan:
- Starta bisect-kommandot :
git bisect start - Nämn dåligt id:
git halvera dåligt HEADellergit bisect c5b3ca8 - Nämn id-id:
git bisect bra v1.0ellergit bisect 93859d8
Detta halverar åtagandeshistorikområdet ungefär halvvägs mellan de goda och dåliga åtagandena som leder oss till åtagande-id: f61a7e8
Följaktligen har kommandot checkat ut projektversionen som den var i detta engagemangs-id. Låt oss nu gå vidare och testa vår ansökan igen.
Kommando för att köra programmet : $./scripts/myApplication.sh[testar andra gången]
Sedan ansökan passerade i detta åtagande är detta åtagande verkligen inte det dåliga åtagandet. Så, nästa, måste du informera samma till kommandot bisect som - $git halva bra
Nu kommer detta att ytterligare begränsa sökresultatet till den första halvan av intervallet som visas -
Testa din ansökan igen - Kommando: $./scripts/myApplication.sh[testar tredje gången]
Så eftersom vi ser ett fel som ovan är detta ett dåligt engagemang.
Låt kommandot bisect veta, kör $git bisect dåligt
Det begränsar sökningen ytterligare och tar dig till den sista blå omringade mittrevisionen: a6ac769
Så jag testar min ansökan en sista gång med samma kommando: $./scripts/myApplication.sh[testar fjärde gången]
Nu, eftersom applikationen misslyckades igen, är det fortfarande ett dåligt åtagande. Så kan vi köra följande kommando:
Kör kommandot: git bisect dåligt
Dåligt åtagande hittades
Detta avslutar det enda sista åtagandet kvar som är dåligt-
java hur man konverterar dubbel till int
Så du vet att det var här koden bröt. Vad händer nu?
Förstå vilken fil som hade felet
I det här fallet ger utdata dig minimal information om begå id , författarens namn , och den författad datum tillsammans med begå meddelande och den väg som modifierades.
Om du vill felsöka ytterligare måste du läsa de begå id-objekt .
Kommando: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
Detta läser engagemangsobjektet och skriver ut loggmeddelandet och textdifferensen.
Du kan lika gärna använda kommandot 'git blame' för att analysera hur och i vilket engagemang varje rad ändrades av vilken författare, kör kommandot som:git skuldkod / utveckla_nav.sh
Stoppa sökningen
För att stoppa sökningen, använd följande kommando:
Kommando: git bisect reset
Således stoppas halveringsprocessen och du är tillbaka på den gren som du startade sökningen från. Nu är nästa steg att fixa eller felsöka koden.
Hur fixar / felsöker jag koden?
Det finns ett par lösningar som du kan göra för att åtgärda det aktuella tillståndet för projektet nu när du har identifierat det åtagande som i första hand ledde till felet.
Men om du ändrar ett åtagande om en delat arkiv det är bäst att återgå ändringen med hjälp av git återgå 'Kommando.
Uppgift: Återställ ändringarna som gjorts av det nämnda dåliga åtagandet
Kommando: git revert a6ac769
Som ett resultat gjorde två saker att återställa ändringarna som gjorts av detta åtagande:
- Det raderade de sista tre tillagda raderna (anges i grönt) och läggs till den raderade raden (anges i rött) tillbaka. (omvänd av a6ac769)
- Skapade ett extra engagemang med informationen om återställningsmeddelande
'Kommandot Återställ gör det också lättare att spåra ändringen du har återställt från det ursprungliga åtagandet'
Använd 'show' kommando igen för att läsa objekt-id, som så-
Kommando: git show 801f029
Gå nu vidare och testa ansökan. Det kommer att köras ordentligt.
Kommando: $./scripts/myApplication.sh
Däremot, om du vill ta bort det dåliga åtagandet från historiken:
Du kan använda
git reset'Kommando med'--hård”Alternativ (men rekommenderas inte i ett delat arkiv).Kolla in en tidigare version av en enda fil med hjälp av
git kassan'Kommando med'-”Alternativ.
Det bör noteras, detta kommer bara att göra ändringar i ditt lokala förråd tills du flyttar ändringarna till ett fjärrförvar. Eftersom vissa ändringar skapar nytt engagemangs-ID som i vårt fall ovan i sådana fall avvisas ett normalt tryck till fjärrförvaret eftersom historien skulle ha avvikit. Du måste använda git push 'Kommando med'--tvinga”Alternativ.
Uppdatera 'master' -grenen
Medan jag fixade felet på min 'dev' -gren kan jag nu slå samman denna förändring med 'master' -grenen också-
- växla till 'master', kommando:
git checkout master - dra senaste uppdateringarna från 'origin / master' till 'master', kommando:
git pull-ursprung - slå samman 'dev' ändringar, kommando:
git merge jätte
Din sammanslagning kan dock generera konflikter om det finns fler åtaganden från fjärrförvaret. Lös konflikter och fortsätt med sammanslagningen.
Slutligen, tryck bara på den stabila 'master' -grenen som förbinder sig till fjärrförvaret medan du gör ditt smutsiga arbete (bug, funktioner, förbättringar) bara på funktionsgrenarna som 'dev' i detta exempel.
Dessutom är det bäst att anta en logisk förgreningsstrategi för att effektivisera och säkra din git-arbetsflödesprocess.
Sammanfattningsvis är 'git bisect' ett praktiskt och användbart kommando som snabbt identifiera de begå id det där infördes till fel i din löpkod med hjälp av en omfattande binär sökning genom logiskt dela kommandot loggar halvvägs mellan Bra och dålig begå räckvidd . Avslutningsvis lärde du dig upptäcka, detektera felaktigt begå och återgå den förändring som gjorts av den.
För underkommandona 'bra' och 'dålig' kan du också använda termer som nya och gamla för att beskriva revisionstillståndet. Du kan köra kommandot flera gånger och skicka olika underkommandon och revision / commit-id för att identifiera olika commit-id (she-1). Alternativt kan ett automatiskt testskript också köras för att bygga den trasiga koden med det här kommandot. Hitta också en detaljerad beskrivning av detta kommando genom att köragit bisect - hjälppå terminalen. Så folk med detta kommer vi till ett slut på den här artikeln om Git Bisect.
js får gruppens längd
Avsikten med DevOps är att skapa programvara av bättre kvalitet snabbare och med mer tillförlitlighet samtidigt som man bjuder in större kommunikation och samarbete mellan team. Om du är intresserad av den här artikeln, c heck ut av Edureka, ett pålitligt inlärningsföretag online med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka DevOps Certification Training-kursen hjälper eleverna att förstå vad som är DevOps och få expertis inom olika DevOps-processer och verktyg som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack och GIT för att automatisera flera steg i SDLC.
Har du en fråga till oss? Vänligen nämna det i kommentarsektionen i ”Git Bisect” -artikeln så återkommer vi till dig ASAP.