advanced git commands
Denne opplæringen utforsker nyttige Git-kommandoer som Git Stash, Git Reset, Git Cherry Pick, Git Bisect og forklarer hvordan du integrerer GitHub med Jira:
I våre tidligere opplæringsprogrammer i denne serien har vi sett de fleste funksjonene i GitHub.
I denne opplæringen vil vi se på følgende:
- Opprette utgivelser
- Integrasjon med Atlassian Jira
- Mest brukte Git-kommandoer for utviklere
- Git Stash
- Git Cherry Pick
- Git Reset
- Git Bisect
=> Ta en titt på GitHub-guiden her.
kvalitetsanalytiker intervju spørsmål og svar
Hva du vil lære:
- Opprette utgivelser
- GitHub-integrasjon med Jira
- Avanserte Git-kommandoer for utviklere
- Konklusjon
- Anbefalt lesing
Opprette utgivelser
Utgivelser i GitHub brukes til å pakke programvaren din, legge til versjonsmerknader og binærfiler (WAR, EAR, JAR-filer) slik at kunder og folk kan bruke det samme.
For å opprette en utgivelse, gå til hovedsiden til depotet og klikk på Utgivelser fanen under Administrer emner.
Klikk på Opprett en ny utgivelse.
Gi en merkelapp og en utgivelsestittel. Binærfilene blir også lagt til utgivelsen. Når du er ferdig, klikk på Publiser utgivelse.
Utgivelsen er nå klar med kildekoden og binærfiler.
GitHub-integrasjon med Jira
En av de viktige sporbarhetsaspektene er å referere til Jira-problemet med forpliktelsene i GitHub. GitHub kan integreres med Jira, ikke bare for å referere til problemet, men også for å bidra til å lage filialer og Pull Request fra Jira.
Så typisk, når utvikleren begynner å jobbe med oppgaven eller feilene, opprettes en gren av ham. Legg ut utviklingen eller løse feilene, en trekkforespørsel kan opprettes fra Jira for å slå seg sammen med hoveddelen herre gren. Grenen opprettet av utvikleren kan deretter slettes.
For å sette opp integrasjonen har vi brukt et plugin Git Integration for Jira. Dette er et kommersielt plugin. Plugin kan lastes ned fra her
Installer pluginet i Jira fra Administrator -> Tillegg.
Når plugin er installert, gå til Søknad -> Git Repositories og koble til GitHub.
Skriv inn GitHub brukernavn og passord. Klikk Koble .
Lagringsplassene som er nevnt for brukerkontoen vises. Klikk på Importer arkiver for å fullføre integrasjonsoppsettet.
GitHub forplikter seg til Jira-utgaven
Som en del av forpliktelsesmeldingen, skriv inn som vist nedenfor. Klikk på Forplikte endringer .
Eksempel 1: Nedenfor er et eksempel på Smart forpliktelse som tillater utviklerne å utføre handlinger på Jira-problemene fra forpliktelsesmeldingen. En slik kommando er #kommentar sammen med Issue-tasten som legger til kommentaren til Jira-problemet som vist nedenfor.
Kommentarseksjonen er oppdatert.
Eksempel 2: Tildel til en bruker og oppdater tiden brukt som 4 timer.
Bruke #tildele og #tid smart kommandokommando i kommittemeldingen.
Begge handlingene er fullført.
Eksempel 3: Endre statusen til problemet I prosess .
Lag en gren
Når oppgaver og feil blir tildelt utviklere, må de begynne å jobbe med utviklingen. For dette lager de en filial for emnet de jobber med, gjør utviklingsaktivitetene og reiser en pull-forespørsel om å slå seg sammen i mastergrenen.
I Jira-utgaven klikker du på Lag gren.
Klikk på Lag gren.
I GitHub gjør du en endring i filen i den ovenfor opprettede grenen og begår det samme.
Etter hvert som utviklingen er fullført, kan brukeren deretter hente en Pull Request fra Jira.
Klikk på nederst i utgaven Opprett Pull Request.
Klikk på Skape. Pull Request vil bli vist som Open.
Neste trinn er å slå sammen pull-forespørselen i GitHub.
Status oppdateres tilsvarende i Jira.
Avanserte Git-kommandoer for utviklere
I denne siste delen vil vi se på noen av de mest brukte Git-kommandoene for utviklere. Ingenting å gjøre med GitHub, men vil hjelpe utviklerne før de skyver endringene til GitHub.
Git Stash
I de fleste av prosjektscenariene når du jobber med en ny funksjon eller forbedring, vil det plutselig være et behov for deg å jobbe med en presserende mangel som er rapportert og er en showstopper. Når du er midt i ditt nye arbeid og ikke fullfører det, er det ingen vits i å begå endringene som er halvferdig.
Så det er bedre å suspendere eller lagre det halvferdige arbeidet midlertidig, jobbe med feilen og komme tilbake til arbeidet med den nye funksjonen eller forbedringen. Git stash gir en løsning på dette. Du kan enkelt bytte sammenheng med å gjøre endringer raskt.
Eksempel 1 :Anta at du jobber med en oppgave som er tildelt deg, og når du ser på statusen, viser det at den ikke er sporet per nå.
Plutselig er det en høyt prioritert feil tildelt deg. Dermed må vi midlertidig lagre eller lagre arbeidet som det arbeides med for tiden.
Kjør følgende kommando.
git stash lagre “Message”
For øyeblikket er arbeidskatalogen ren. Eventuelle nye forpliktelser kan gjøres, og hvis det er feil, kan du bytte gren for å jobbe med det osv.
Når du vil bruke endringene der du hadde igjen, bruker du kommandoen.
git stash pop
Kommandoen ovenfor fjerner stash fra listen og vil bruke den sist lagrede tilstanden.
Du kan også bruke:
git stash gjelder
Ovennevnte kommando vil beholde endringene i stash og ikke fjerne dem.
Nå er endringene brukt på nytt, og du kan begå endringene.
Eksempel 2: Stash endringene dine, bytt gren og slå sammen endringer.
Gjør endringen til Html-filen i herre gren og stash endringer.
Neste er å bytte til feil filial, gjør endringer og foreta endringer.
git checkout -b bug
Gjør endringer i HTML-filen.
git commit -a -m “Fixed email issue”
Bytt tilbake til herre gren og bruk endringer fra stash på nytt.
Nå fusjonere fra feil gren til herre gren. Foreta endringene etter sammenslåingen.
Eksempel 3: Arbeide med flere stash.
I den lokale repoen er det 2 HTML-filer. Så det er mulig at flere utviklere vil jobbe med flere filer og stash endringer etter behov for å jobbe med presserende forespørsler som kommer deres vei for å fikse endringene.
Utvikler 1 fungerer på hello.html og utvikler 2 fungerer på index.html.
Utvikler 1
Stash-listen har 1 oppføring nå.
Utvikler 2
Stash-listen har nå 2 oppføringer. Den siste stashen er først i stakken som er stash @ {0}. Nå kan begge utviklerne gjøre andre forpliktelser raskt eller jobbe med en annen gren og deretter komme tilbake til herre gren og bruk stashendringene.
For å bruke den siste stashen, kan du bare løpe
git stash pop
For å bruke et bestemt stash i stakken, kjør følgende kommando.
git stash pop stash @ {1}
La oss bruke den andre stashen som er stash @ {1}
På samme måte kan den andre stashen brukes.
Git Cherry Pick
I dag jobber utviklerne på flere grener som funksjon, forbedring, bug osv.
Det er situasjoner der bare et par spesifikke forpliktelser trenger å bli plukket og ikke slå sammen hele grenen til en annen gren. Dette kalles en Cherry Pick. Denne prosessen lar deg vilkårlig velge hvilken som helst Git-forpliktelse fra de andre grenene og legge den til gjeldende HEAD for arbeidstreet.
Eksempel 1:
I det lokale git-depotet har vi følgende 6 filer.
Én fil slettes, si file5.txt.
Foreta endringene.
Se på loggen nå. File5.txt slettes.
Så vi vil Cherry-Pick forplikte der vi la til file5.txt. Vi må finne kommisjons-IDen for file5.tx og kjøre kommandoen.
git cherry-pick
I dette tilfellet er kommisjons-ID-en for når file5.txt ble lagt til a2f0124
File5.txt er nå gjenopprettet. Vi valgte kirsebær.
Eksempel 2:
La oss bare endre file6.txt og begå endringene i herre gren.
Se på den andre linjen inn file6.txt der e-postadressen ikke er spesifisert riktig.
Opprett en feilfil og fikse problemet. Samtidig endrer du file5.txt også slik at vi har flere forpliktelser gjort i feilgrenen, men Cherry-Pick bare forpliktelsen gjort i file6.txt.
File6 endret i feil gren.
Så generelt sett har vi gjort endringer i file5 og file6 i Bug-grenen.
La oss nå bytte tilbake til herre filial og Cherry-Pick forpliktelsen bare gjort for file6.txt.
Som du kan se at i stedet for å slå sammen feil gren inn i herre gren, har vi bare Cherry-Picked bare en bestemt forpliktelse og brukt i hovedgrenen.
Git Reset
Git reset er en kraftig kommando for å angre lokale endringer. Så, for å fjerne scenen, brukes alle de iscenesatte filene denne kommandoen.
Eksempel
Endre en fil og legg den til iscenesettingen. Tilbakestill med kommandoen som vist når de iscenesatte endringene ikke er iscenesatt.
Parametere for git reset kommando.
-myk: Denne parameteren vil peke HEAD til en annen forpliktelse. Alle filer endres mellom den opprinnelige HEAD og forpliktelsen vil bli iscenesatt. Arbeidskatalogen er intakt.
Se på gjeldende HEAD-plassering.
La oss gå tilbake fem forpliktelser i historien.
Foreta endringene på nytt.
–Blandet: Alternativet ligner på den myke parameteren. Vanligvis, når det er noen dårlige forpliktelser, fjerner du dem og retter det senere og forplikter det tilbake. Så egentlig må vi legge til i indeksen ved hjelp av git add og så git begå. Endringer er igjen i arbeidstreet.
La oss gå tilbake to forpliktelser i historien og se at filene ikke blir sporet.
Nå legger du til filene i iscenesettelsen og begår endringene.
-hard: Denne parameteren vil hvile til et punkt der en bestemt fil eksisterte. Endringene vil ikke være tilgjengelige i arbeidstreet.
Når du ser på loggen ovenfor, kan vi gå tilbake til det punktet hvor bare fil 1 ble begått, dvs. den siste oppføringen.
Ved hjelp av git reset –hard
Git Bisect
Finn den nøyaktige forpliktelsen som brøt koden (Vi er tross alt mennesker). Ofte under testing av applikasjonen hører vi fra testerne våre at det er en feil, eller at funksjonen er ødelagt, og du som utvikler vil si at den fungerte forrige uke. Så, hva skjedde og hvorfor dukket denne feilen opp?
Noen ganger kan en endring i den andre koden ha påvirket funksjonen din. Du må bruke tid på å gå gjennom historien der det er mange forpliktelser som er tidkrevende og vanskelig å spore hvilken endring som førte til at koden brøt.
Git Bisect er kommandoen for å finne den eksakte forpliktelsen da feilen ble introdusert. Med Git bisect må du velge to forpliktelser, en god og en dårlig. Omtrent halvveis mellom begge forpliktelsene blir sjekket ut. Du sjekker hver forpliktelse enten dårlig eller god til forpliktelsen som forårsaket at feilen eller koden brøt, er funnet.
Eksempel:
- Opprett et nytt lokalt git-arkiv og opprett en fil som heter index.html
- Første innhold av filen som vist.
- Legg til iscenesettelse og forplikt deg til depotet.
- Lag en historie med forpliktelser som vist, slik at vi kan velge mellom gode og dårlige forpliktelser. Nå som den første forpliktelsen er ferdig, gjør du de andre endringene som vist og begår det samme. Totalt sett vil vi gjøre 7 forpliktelser.
Andre endring
Tredje endring
Fjerde endring
Femte endring
Sjette endring
Syvende endring
La oss stoppe her. Så vi har syv forpliktelser.
Hvis du ser på HTML-siden, er linjene etter 'Alle de 4 hendelsene ...' feil, og dokumentasjonen er dermed ikke riktig. Så vi må finne forpliktelsen der feilen ble introdusert, slik at vi kan hvile hodet til det forpliktelsen.
La oss se på loggen og finne ut dårlig og god forpliktelse.
Den siste forpliktelsen er ikke riktig, så det kan være en dårlig forpliktelse. Forpliktelsen ble introdusert etter den tredje forpliktelsen, slik at vi kan ha Tredje endring som de gode forplikter.
Prosessen med halvering starter med git bisect start og ender med git bisect reset.
git bisect dårlig // Da siste forpliktelse er dårlig. Ingen grunn til å oppgi kommisjons-ID.
git bisect bra
Du kan nå se at HODET nå er mellom halvparten av det dårlige og gode forpliktelsen.
Se på innholdet i index.html og se om det er en god forpliktelse. Hvis ikke, blir feilen fortsatt ikke funnet.
Egentlig ikke at feilen fortsatt eksisterer. Den siste linjen er feil. Så vi kjører ‘ git bisect bad ’. Det er fortsatt en dårlig forpliktelse, og det nåværende innholdet er ikke akseptabelt.
Ovennevnte innhold er riktig og akseptabelt.
Kjør ‘git log –oneline’ og ‘git bisect good’.
Så Femte endring var den første dårlige forpliktelsen og virkelig det. Feilen er identifisert.
Gjeldende innhold skal være i den endelige dokumentasjonen.
Når den dårlige forpliktelsen er identifisert, kan du informere utvikleren om å rette på endringene som kan være for å tilbakestille hodet til den fjerde endringen som var den siste gode forpliktelsen.
Løpe ' git bisect reset For å avslutte prosessen.
Konklusjon
I denne GitHub hands-on primeren har vi prøvd å dekke alt som en utvikler trenger å jobbe med, dvs. fra versjonskontroll og sporingsperspektiv.
I de tre første opplæringene i GitHub-serien har vi lært om versjonskontrollaktiviteter, oppretting av arkiver, pull-forespørsel, filialer, kodevurderinger, organisasjoner og team, gaffel et depot, etiketter, milepæler, problemer, prosjektbrett, wikier, utgivelser, integrering med Jira og noen ofte brukte Git-kommandoer for utviklere.
Vi håper virkelig at alle utviklerne vil finne denne praktiske tilnærmingen for GitHub og Git-kommandoene nyttige i sine prosjekter.
=> Les gjennom Easy GitHub Training Series.
Anbefalt lesing
- GitLab Jira Integration Tutorial
- Unix-kommandoer: Grunnleggende og avanserte Unix-kommandoer med eksempler
- Selenintegrasjon med GitHub ved hjelp av formørkelse
- JIRA og SVN Integration Tutorial
- Git vs GitHub: Utforsk forskjellene med eksempler
- Agurk Selen Tutorial: Agurk Java Selen WebDriver Integration
- GitHub-veiledning for utviklere | Slik bruker du GitHub
- Unix Pipes Tutorial: Pipes in Unix Programming