Als u zich in een vergelijkbare situatie bevindt en het niet weet welke verandering brak de code of WHO uit vele bijdragers bezit deze bug / functie , dan is git bisect jouw uitweg. Dus in dit artikel over git bisect leer je hoe de ‘git halveren‘Commando komt naar rescue bij het detecteren van de eerste slechte commit die de bug introduceert met behulp van het binaire zoekalgoritme.
De onderwerpen die in dit artikel worden behandeld, zijn als volgt:
Waarom git bisect gebruiken?
Het lijdt geen twijfel dat je de neiging hebt om een aantal commits te maken voor elke kleine wijziging in . In een dergelijk scenario wordt het debuggen van de code een vervelende taak, omdat u handmatig terug in de tijd moet gaan naar elke afzonderlijke revisie van de project-snapshot om de werkende code te testen en de bug te detecteren. Nu wordt dit zelfs nog meer complex als je andermans werk te inspecteren hebt zonder een leidend punt, klinkt het ook niet erg haalbaar om iedereen te vragen zijn eigen fouten op te ruimen.
Onderweg zou je ook een aantal ‘feature’ (of hotfix) branches in het proces kunnen maken en weggooien en uiteindelijk tijd en moeite verspillen terwijl je afwijkt van de hoofdlijn van ontwikkeling.
Om dergelijke scenario's te vermijden, kunt u degit halverencommando om de slechte projectrevisie (of momentopname) te vinden en deze uiteindelijk te repareren met degit revertopdracht.
Hoe zoekt ‘git bisect’?
Dit commando doorsnijdt (verdeelt) uw geschiedenis tussen de is goed en de slecht plegen bereik. Het wijst je stroom project staat naar een middenbereik plegen momentopname. Het git bisect commando gaat dan door elke commit-id tussen dit bereik while pauzeren bij elke momentopname zodat u dit kunt doen test de code . Als de bug bestaat, declareert u de commit als slecht, zo niet zoals is goed tenzij de zoektocht eindigt.
Syntaxis
git halveren
Om git bisect beter te begrijpen, laten we een project maken dat de code ontwikkelt voor een eenvoudige navigatie-app die in een auto kan worden gebruikt.
Initiële projectconfiguratie
Om een project te maken dat de code ontwikkelt voor een eenvoudige navigatie-app voor gebruik in een auto, volg je de onderstaande stappen:
Stap 1: Maak een nieuwe map in uw $ HOME-map:
cd $ HOME mkdir my_nav_app
Stap 2: Navigeer naar de nieuwe directory:
cd $ my_nav_app
Stap 3: Kloon om het project te downloaden van mijn GitHub-pagina:
git clone https://github.com/divyabhushan/my_nav_app.git
Laten we nu de lay-out van de projectmappen en bestanden begrijpen, zoals afgedrukt met de opdracht:ls -lTR
Laten we vervolgens het projecthistoriejournaal bekijken om de commits te bekijken die ik heb gemaakt om deze code te genereren-
Een eenvoudig git log-commando drukt bijvoorbeeld de geschiedenis in detail af, maar ik vind het leuk om de geschiedenis mooi op te maken en aan te passen. Laat het ons daarbij stel een aliasnaam in - ‘hist’ de ... gebruiken git alias commando zoals hieronder getoond:
git alias.hist 'log --pretty = format:'% C (geel)% h% Creset% ad | % C (groen)% s% Creset% C (rood)% d% Creset% C (blauw) [% an] '--graph --decorate --date = short'
Nu ga ik deze functie voor het repareren van bugs in een aparte branch uitvoeren, om de hoofdontwikkeling op de ‘master’ branch niet te verstoren. Volg hiervoor de onderstaande reeks opdrachten:
- Maak branch ‘dev’ aan: [meester] $
git branch dev - Schakel over naar branch ‘dev’: $
git checkout dev - Maak een lijst van de geschiedenislogboeken: [dev] $
ga hist[Opmerking: hier wordt de opdracht ‘alias 'gebruikt]
Verder heb ik de laatst bekende goede commit gemarkeerd waarvan ik weet dat mijn script goed werkte met de verwachte testcaseresultaten, deze commit-momentopname is getagd als v1.0.
Dus nu we onze laatste goede commit kennen, laten we verder gaan in dit artikel over ‘git bisect’ en de applicatie testen.
Test de applicatie
Voer het script uit als - $./scripts/myApplication.sh[eerste keer testen]
Het is duidelijk dat mijn huidige projectstaat zich in fout , en ik weet niet zeker welke wijziging ik heb aangebracht in welke commit die deze wijziging heeft geïntroduceerd. Laten we nu, in dit artikel over git bisect, eens kijken hoe we de slechte commit kunnen identificeren.
Identificatie van de slechte commit
Om te beginnen met het inspecteren op de slechte commit, zou je de onderstaande stappen moeten volgen:
- Start de opdracht in twee delen :
git halveren start - Noem de slechte commit-ID:
git halveren slechte HEADofgit halveren c5b3ca8 - Noem de laatst bekende-goede-commit-id:
git halveren goede v1.0ofgit halveren 93859d8
Dit deelt het bereik van de commit-geschiedenis ongeveer halverwege tussen de goede en slechte commits die ons bij de commit-id brengt: f61a7e8
Daarom heeft het commando de projectversie uitgecheckt zoals het was in deze commit-id. Laten we nu doorgaan en onze applicatie opnieuw testen.
Commando om de applicatie uit te voeren : $./scripts/myApplication.sh[tweede keer testen]
Sinds de aanvraag geslaagd in deze commit is deze commit zeker niet de slechte commit. Dus vervolgens moet u hetzelfde doorgeven aan het halffabrikaat als - $git halveren goed
Dit zal het zoekresultaat nu verder beperken tot de eerste helft van het bereik, zoals weergegeven -
Test uw applicatie opnieuw - Commando: $./scripts/myApplication.sh[derde keer testen]
Dus, aangezien we een fout zien zoals hierboven, is dit een slechte commit.
Laat het halveren commando weten, voer $ uitgit halveren slecht
Dat verkleint de zoekopdracht verder en brengt je bij de laatste blauw omcirkelde middelste revisie: a6ac769
Dus ik test mijn applicatie nog een laatste keer met hetzelfde commando: $./scripts/myApplication.sh[vierde keer testen]
Nu de applicatie opnieuw is mislukt, is het nog steeds een slechte commit. Dus laten we het volgende commando uitvoeren:
Voer het commando uit: git halveren slecht
Slechte commit gevonden
Dit is het einde van de enige laatste commit die nog over is die slecht is-
Dus je weet dat hier de code is gebroken. Wat nu?
Begrijp welk bestand de bug bevat
In dit geval geeft de uitvoer u minimale informatie over het commit-id , auteur naam , en de auteur datum samen met de commit bericht en de pad dat is gewijzigd.
Als u verder wilt debuggen, moet u lezen de commit id-object .
Opdracht: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
Dit zal het commit-object lezen en het logbericht en de tekstuele diff afdrukken.
Je kunt net zo goed het ‘git blame’ commando gebruiken om te analyseren hoe en in welke commit elke regel is veranderd door welke auteur, voer het commando uit als:git schuld code / Develop_nav.sh
Stop met zoeken
Gebruik de volgende opdracht om het zoeken te stoppen:
Opdracht: git bisect reset
Het deelproces wordt dus gestopt en u bent weer terug op de tak van waaruit u met zoeken bent begonnen. Nu is de volgende stap het repareren of debuggen van de code.
Hoe de code repareren / debuggen?
Welnu, er zijn een aantal tijdelijke oplossingen die u zou kunnen doen om de huidige staat van het project op te lossen nu u de commit hebt geïdentificeerd die de bug in de eerste plaats veroorzaakte.
Als je echter een commit wijzigt op een gedeelde repository het is het beste om terugdraaien de wijziging met de ‘ git revert ‘Commando.
Taak: Herstel de wijzigingen die zijn aangebracht door de genoemde slechte commit
Opdracht: git terugzetten a6ac769
Als resultaat heeft het terugdraaien van de wijzigingen die door deze commit zijn gemaakt 2 dingen gedaan:
- Het verwijderde de laatste 3 toegevoegde regels (aangegeven in groen) en voegde de verwijderde regel (aangegeven in rood) weer toe. (achterkant van a6ac769)
- Een extra commit gemaakt met de informatie over het terugdraaien van berichten
'Revert-commando maakt het ook gemakkelijker om de wijziging bij te houden die je hebt teruggedraaid van de oorspronkelijke commit'
Gebruik de 'tonen' opdracht opnieuw om de object-id te lezen, zoals
Opdracht: git show 801f029
Ga nu verder en test de applicatie. Het zal correct worden uitgevoerd.
Opdracht: $./scripts/myApplication.sh
Als je daarentegen de slechte commit uit de geschiedenis wilt verwijderen:
Je zou de ‘
git reset‘Commando met de‘--moeilijk”Optie (hoewel niet aanbevolen in een gedeelde repository).Bekijk een eerdere versie van een enkel bestand met de ‘
git checkout‘Commando met de‘-' keuze.
Opgemerkt moet worden dat hierdoor alleen wijzigingen in uw lokale repository worden aangebracht totdat u de wijzigingen naar een externe repository pusht. Aangezien sommige wijzigingen een nieuwe commit-object-id creëren, zoals in ons geval hierboven, wordt in dergelijke gevallen een normale push naar de externe repository afgewezen omdat de geschiedenis zou zijn gedivergeerd. U moet de ‘ git push ‘Commando met de‘--dwingen' keuze.
Werk de ‘master’ branch bij
Terwijl ik de bug op mijn ‘dev’ branch repareerde, kan ik deze wijziging nu ook samenvoegen met de ‘master’ branch:
- schakel over naar ‘master’, commando:
git checkout master - haal recente updates van ‘origin / master’ naar ‘master’, opdracht:
git pull oorsprong - samenvoegen ‘dev’ wijzigingen, commando:
git merge gigant
Uw samenvoeging kan echter conflicten veroorzaken als er meer commits uit de externe repository komen. Los conflicten op en ga door met het samenvoegen.
Tenslotte, push alleen de stabiele ‘master’ branch commits naar de remote repository terwijl je je vuile werk (bug, features, verbeteringen) alleen doet op de feature branches zoals ‘dev’ in dit voorbeeld.
Bovendien is het het beste om een logisch aan te nemen vertakking strategie om uw git-workflowproces te stroomlijnen en te beveiligen.
Om samen te vatten, ‘git bisect’ is een handig en nuttig commando dat snel identificeren de commit-id dat geïntroduceerd naar fout in uw lopende code met behulp van een uitgebreide Binaire zoekopdracht door logisch verdelen de commit logs halverwege tussen de is goed en slecht plegen bereik . Tot slot: je hebt het geleerd detecteren de foutieve commit en terugdraaien de verandering die erdoor is aangebracht.
implementeren prioriteit wachtrij c ++
Naast de subopdrachten ‘goed’ en ‘slecht’ kunt u ook termen als nieuw en oud gebruiken om de revisiestatus te beschrijven. Je kunt het commando meerdere keren uitvoeren door verschillende subcommando's en revisie / commit-id's door te geven om verschillende commit-id's (she-1) te identificeren. Als alternatief kan ook een geautomatiseerd testscript worden uitgevoerd om met deze opdracht de gebroken code samen te stellen. Zoek ook een gedetailleerde beschrijving van deze opdracht door uit te voerengit bisect --helpop de terminal. Dus mensen hiermee komen we tot een einde aan dit artikel over Git Bisect.
De bedoeling van DevOps is om sneller en betrouwbaarder software van betere kwaliteit te maken en tegelijkertijd meer communicatie en samenwerking tussen teams uit te nodigen. Als je geïntrigeerd bent door dit artikel, c ach uit de door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka DevOps Certification Training-cursus helpt leerlingen te begrijpen wat DevOps is en expertise op te doen in verschillende DevOps-processen en -tools zoals Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack en GIT voor het automatiseren van meerdere stappen in SDLC.
Heeft u een vraag voor ons? Vermeld het in de commentarensectie van het artikel 'Git Bisect' en we nemen zo snel mogelijk contact met u op.