Hvis du er i en lignende situasjon og ikke vet hvilken endring brøt koden eller WHO ut av mange bidragsytere eier dette feil / funksjon , så er git bisect din vei ut. Så, i denne artikkelen om git bisect vil du lære hvordangit bisect‘Kommando kommer til redning ved å oppdage den første dårlige forpliktelsen som introduserer feilen ved hjelp av den binære søkealgoritmen.
Temaene som dekkes i denne artikkelen er som følger:
Hvorfor bruke git bisect?
Det er ingen tvil om at du har en tendens til å opprette en rekke forpliktelser for hver mindre endring i . I et slikt scenario blir feilsøking av koden en kjedelig oppgave, da du må manuelt gå tilbake i tid til hver eneste revisjon av prosjektbildet for å teste arbeidskoden og oppdage feilen. Nå blir dette enda mer komplisert når du har andres arbeid for å inspisere uten et ledepunkt, høres det heller ikke veldig mulig å be hver om å rydde opp i sine egne feil.
Underveis kan du også opprette og forkaste en rekke ‘funksjons’ (eller hurtigreparasjons) grener i prosessen og ende opp med å kaste bort tid og krefter mens du avviker fra hovedlinjen for utvikling.
hva er røye i java
Så, for å unngå slike scenarier, kan du brukegit bisectkommando for å finne den dårlige prosjektrevisjonen (eller øyeblikksbildet) og til slutt fikse den medgit tilbakevendkommando.
Hvordan søker ‘git bisect’?
Denne kommandoen halvering (deler) historien din mellom god og dårlig begå område. Det peker på din nåværende prosjekt stat til en mellomklasse begå øyeblikksbilde. Kommandoen git bisect beveger seg deretter gjennom hvert kommisjons-ID mellom dette området mens pause ved hvert øyeblikksbilde slik at du kan test koden . Hvis feilen eksisterer, erklærer du forpliktelsen som dårlig, hvis ikke som god med mindre søket avsluttes.
Syntaks
git bisect
For å forstå git bisect bedre, la oss lage et prosjekt som utvikler koden for en enkel navigasjonsapp som skal brukes i en bil.
Første prosjektoppsett
For å lage et prosjekt som utvikler koden for en enkel navigasjonsapp som skal brukes i en bil, kan du følge trinnene nedenfor:
Trinn 1: Opprett en ny katalog i $ HOME-mappen:
cd $ HJEM mkdir my_nav_app
Steg 2: Naviger til den nye katalogen:
cd $ my_nav_app
Trinn 3: Klone for å laste ned prosjektet fra GitHub-siden min:
git clone https://github.com/divyabhushan/my_nav_app.git
La oss nå forstå prosjektkatalogene og filoppsettet, som skrevet ut av kommandoen:ls -lTR
La oss deretter se prosjekthistorikkjournalen for å se forpliktelsene jeg gjorde for å generere denne koden -
For eksempel, en enkel git log-kommando skriver ut historien i detalj, men jeg liker å formatere og tilpasse historien. La oss derved angi et aliasnavn - ‘hist’ bruker git alias kommandoen som vist nedenfor:
git alias.hist 'log --pretty = format:'% C (gul)% h% Creset% ad | % C (grønn)% s% Creset% C (rød)% d% Creset% C (blå) [% an] '- graf - dekorere - dato = kort'
Nå skal jeg utføre denne feilrettingsfunksjonen i en egen gren, for ikke å forstyrre hovedutviklingen på 'master' -grenen. For å gjøre det, følg nedenstående sett med kommandoer:
- Lag gren ‘dev’: [master] $
git branch dev - Bytt til avdeling ‘dev’: $
git checkout dev - Liste historikkloggene: [dev] $
gå hist[Merk: 'alias' -kommandoen som brukes her]
Videre har jeg fremhevet det sist kjente gode forpliktelsen som jeg vet der skriptet mitt fungerte bra med forventede testresultater, dette forpliktelses øyeblikksbildet er merket som v1.0.
Så nå som vi vet vårt siste gode forpliktelse, la oss gå videre i denne artikkelen om ‘git bisect’ og teste applikasjonen.
Test applikasjonen
Kjør skriptet som - $./scripts/myApplication.sh[tester første gang]
Det er klart at min nåværende prosjekttilstand er i feil , og jeg er ikke sikker på hvilken endring jeg gjorde i hvilken forpliktelse som introduserte denne endringen. Så, neste i denne artikkelen om git bisect, la oss se hvordan vi kan identifisere den dårlige forpliktelsen.
Identifikasjon av dårlig forpliktelse
For å begynne å inspisere for dårlig forpliktelse, følger du trinnene nedenfor:
- Start bisect-kommandoen :
git bisect start - Nevn id for dårlig forpliktelse:
git bisect dårlig HODEellergit bisect c5b3ca8 - Nevn ID-en som er sist kjent-god-forpliktelse:
git bisect god v1.0ellergit bisect 93859d8
Dette halverer forpliktelseshistorieområdet omtrent midt mellom de gode og dårlige forpliktelsene som bringer oss til forpliktelses-id: f61a7e8
Derfor har kommandoen sjekket ut prosjektversjonen slik den var i denne kommisjons-IDen. La oss nå teste søknaden vår på nytt.
Kommando for å kjøre applikasjonen : $./scripts/myApplication.sh[tester andre gang]
Siden søknaden bestått i denne forpliktelsen er denne forpliktelsen absolutt ikke den dårlige forpliktelsen. Så, neste, må du informere det samme til bisect-kommandoen som - $git bisect bra
Nå vil dette begrense søkeresultatet ytterligere i første halvdel av området som vist -
Test søknaden din på nytt - Kommando: $./scripts/myApplication.sh[tester tredje gang]
Så siden vi ser en feil som ovenfor, er dette en dårlig forpliktelse.
Gi beskjed om bisect, kjør $git bisect dårlig
Dette begrenser søket ytterligere og bringer deg til den siste blå omkransede midtrevisjonen: a6ac769
Så jeg tester søknaden min en siste gang med samme kommando: $./scripts/myApplication.sh[tester fjerde gang]
Nå, siden applikasjonen mislyktes igjen, er det fortsatt en dårlig forpliktelse. Så la oss kjøre følgende kommando:
Kjør kommandoen: git bisect dårlig
Dårlig forpliktelse funnet
Dette avslutter det eneste siste igjen som er dårlig -
Så du vet at det er her koden brøt. Hva nå?
Forstå hvilken fil som hadde feilen
I dette tilfellet gir utdataene deg minimal informasjon om begå id , forfatternavn , og forfatterdato sammen med begå melding og sti som ble endret.
Hvis du vil feilsøke videre, må du lese de begå id-objekt .
Kommando: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
Dette vil lese kommittobjektet og skrive ut loggmeldingen og tekstdifferansen.
Du kan like godt bruke kommandoen ‘git blame’ til å analysere hvordan og i hvilken forpliktelse hver linje ble endret av hvilken forfatter, kjør kommandoen som:git skyldkode / utvikle_nav.sh
Stopp søket
For å stoppe søket, bruk følgende kommando:
Kommando: git bisect reset
Dermed stoppes halveringsprosessen, og du er tilbake på grenen du startet søket fra. Nå er neste trinn å fikse eller feilsøke koden.
Hvordan fikse / feilsøke koden?
Vel, det er et par løsninger du kan gjøre for å fikse den nåværende tilstanden til prosjektet nå som du har identifisert forpliktelsen som førte til feilen.
Men hvis du endrer en forpliktelse på en delt depot det er best å tilbakestille endringen ved å bruke git tilbakevend ‘Kommando.
Oppgave: Tilbakestill endringene som er gjort av den nevnte dårlige forpliktelsen
Kommando: git revert a6ac769
Som et resultat gjorde to ting å tilbakestille endringene som ble gjort med dette tilsagnet:
- Den slettet de siste 3 tilføyde linjene (angitt i grønt) og la den slettede linjen (angitt i rødt) tilbake. (baksiden av a6ac769)
- Laget en ekstra forpliktelse med informasjonen om tilbakestilling av meldingen
'Tilbakestill kommando gjør det også lettere å spore endringen du tilbakestilte fra den opprinnelige forpliktelsen'
Bruke 'vise fram' kommandoen igjen for å lese objekt-id, som så-
Kommando: git show 801f029
Nå, gå videre og test søknaden. Det vil kjøre ordentlig.
Kommando: $./scripts/myApplication.sh
Hvis du derimot vil fjerne den dårlige forpliktelsen fra historikken:
Du kan bruke
git reset‘Kommando med“--hard”-Alternativet (men ikke anbefalt i et delt arkiv).hva er årsakene til å opprette en forekomst av filklassen?
Sjekk ut en tidligere versjon av en enkelt fil ved hjelp av ‘
git kassa‘Kommando med‘-‘Alternativ.
Det skal bemerkes at dette bare vil gjøre endringer i ditt lokale depot til du skyver endringene til et eksternt depot. Siden noen endringer skaper nytt forpliktende objekt-ID som i vårt tilfelle ovenfor, i slike tilfeller avvises et normalt skyv til det eksterne depotet siden historien ville ha avviket. Du må bruke git push ‘Kommando med‘--makt‘Alternativ.
Oppdater ‘master’ gren
Mens jeg løste feilen på 'dev' -grenen min, kan jeg nå slå sammen denne endringen med 'master' -grenen -
- bytt til ‘master’, kommando:
git checkout master - trekk nylige oppdateringer fra 'origin / master' til 'master', kommando:
git pull opprinnelse - flette 'dev' endringer, kommando:
git fusjon gigant
Imidlertid kan sammenslåingen din generere konflikter hvis det er flere forpliktelser fra det eksterne depotet. Løs konflikter og fortsett med sammenslåingen.
Til slutt, trykk bare den stabile 'master' -grenen forplikter seg til det eksterne depotet mens du får det skitne arbeidet ditt (bug, funksjoner, forbedringer) bare gjort på funksjonsgrenene som 'dev' i dette eksemplet.
Videre er det best å ta i bruk en logisk forgreningsstrategi for å effektivisere og sikre git-arbeidsflytprosessen.
For å oppsummere er ‘git bisect’ en praktisk og nyttig kommando som raskt identifisere de begå id at introdusert til feil i løpekoden din ved hjelp av et omfattende binært søk av logisk dele kommisjonsloggene halvveis mellom god og dårlig begå område . For å avslutte, lærte du å oppdage den defekte forpliktelsen og tilbakestille endringen gjort av den.
I tillegg til underkommandoene 'god' og 'dårlig' kan du også bruke ord som nye og gamle for å beskrive revisjonstilstanden. Du kan kjøre kommandoen flere ganger ved å sende forskjellige underkommandoer og revisjons- / kommisjons-ID-er for å identifisere forskjellige kommisjons-IDer (she-1). Alternativt kan et automatisert testskript også kjøres for å bygge den ødelagte koden ved hjelp av denne kommandoen. Finn også en detaljert beskrivelse av denne kommandoen ved å kjøregit bisect - hjelppå terminalen. Så folkens med dette kommer vi til en slutt på denne artikkelen om Git Bisect.
Intensjonen med DevOps er å lage programvare av bedre kvalitet raskere og med mer pålitelighet, samtidig som man inviterer til større kommunikasjon og samarbeid mellom teamene. Hvis du er fascinert av denne artikkelen, c pokker ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka DevOps Certification Training-kurset hjelper elever til å forstå hva som er DevOps og få ekspertise i forskjellige DevOps-prosesser og verktøy som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT for å automatisere flere trinn i SDLC.
Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet i 'Git Bisect' -artikkelen, så kommer vi tilbake til deg ASAP.