advanced git commands
Denne vejledning udforsker nyttige Git-kommandoer som Git Stash, Git Reset, Git Cherry Pick, Git Bisect & forklarer, hvordan man integrerer GitHub med Jira:
I vores tidligere tutorials i denne serie har vi set de fleste af funktionerne i GitHub.
I denne vejledning ser vi på følgende:
- Oprettelse af udgivelser
- Integration med Atlassian Jira
- Mest anvendte Git-kommandoer til udviklere
- Git Stash
- Git Cherry Pick
- Git Reset
- Git Bisect
j2ee interviewspørgsmål til seniorudviklere
Hvad du vil lære:
- Oprettelse af udgivelser
- GitHub-integration med Jira
- Avancerede Git-kommandoer til udviklere
- Konklusion
- Anbefalet læsning
Oprettelse af udgivelser
Udgivelser i GitHub bruges til at pakke din software, tilføje udgivelsesnotater og binære filer (WAR, EAR, JAR-filer), så kunder og folk kan bruge det samme.
For at oprette en frigivelse skal du gå til hovedsiden i arkivet og klikke på Udgivelser fanen under Administrer emner.
Klik på Opret en ny udgivelse.
Giv et mærke og en frigivelsestitel. Binærfilerne føjes også til udgivelsen. Når du er færdig, skal du klikke på Offentliggør frigivelse.
Udgivelsen er nu klar med kildekoden og binære filer.
GitHub-integration med Jira
Et af de vigtige sporbarhedsaspekter er at henvise til Jira-problemet med forpligtelserne i GitHub. GitHub kan integreres med Jira, ikke kun for at henvise til problemet, men også for at hjælpe med at oprette filialer og Pull Request fra Jira.
Så typisk, når udvikleren begynder at arbejde på opgaven eller bugs, oprettes en gren af ham. Send udviklingen eller løs bugs, der kan oprettes en pull-anmodning fra Jira for at fusionere til main mestre afdeling. Den gren, der er oprettet af udvikleren, kan derefter slettes.
For at konfigurere integrationen har vi brugt et plugin Git-integration til Jira. Dette er et kommercielt plugin. Pluginet kan downloades fra her
Installer pluginet i Jira fra Administrator -> Tilføjelser.
Når pluginet er installeret, skal du gå til Ansøgning -> Git Repositories og opret forbindelse til GitHub.
Indtast GitHub brugernavn og adgangskode. Klik på Forbinde .
De lagre, der er nævnt for brugerkontoen, vises. Klik på Importér arkiver for at afslutte integrationsopsætningen.
GitHub forpligter sig til Jira-problemet
Indtast som en del af forpligtelsesmeddelelsen som vist nedenfor. Klik på Forpligt ændringer .
Eksempel 1: Nedenfor er et eksempel på Smart forpligtelse som gør det muligt for udviklerne at udføre handlinger på Jira-problemerne fra forpligtelsesmeddelelsen. En sådan kommando er #kommentar sammen med Issue-tasten, der tilføjer kommentaren til Jira-problemet som vist nedenfor.
Kommentarafsnittet opdateret.
Eksempel 2: Tildel til en bruger og opdater tid brugt som 4 timer.
Brug # tildel og #tid smart commit-kommando i commit-meddelelsen.
Begge aktioner er afsluttet.
Eksempel 3: Skift status for problemet til I gang .
Opret en filial
Da opgaver og fejl tildeles udviklere, skal de begynde at arbejde på udviklingen. Til dette skaber de en filial til det emne, de arbejder på, gør udviklingsaktiviteterne og rejser en pull-anmodning om at fusionere ind i mastergrenen.
I Jira-problemet nederst skal du klikke på Opret filial.
Klik på Opret filial.
I GitHub foretager du en ændring af filen i den ovenfor oprettede gren og forpligter den samme.
Efterhånden som udviklingen er afsluttet, kan brugeren derefter rejse en Pull-anmodning fra Jira.
Klik på i bunden af problemet Opret trækanmodning.
Klik på Skab. Pull-anmodningen vises som åben.
Det næste trin er at flette pull-anmodningen i GitHub.
Status opdateres i overensstemmelse hermed i Jira.
Avancerede Git-kommandoer til udviklere
I dette sidste afsnit vil vi se på nogle af de almindeligt anvendte Git-kommandoer til udviklere. Intet at gøre med GitHub, men vil hjælpe udviklerne, før de skubber ændringerne til GitHub.
Git Stash
I de fleste af projektscenarierne, når du arbejder på en ny funktion eller forbedring, ville der pludselig være et behov for dig at arbejde på en presserende fejl, der er rapporteret og er en showstopper. Når du er midt i dit nye arbejde og ikke har afsluttet det, er der ingen mening i at begå de ændringer, der er halvt færdige.
Så det er bedre at suspendere eller gemme det halvt udførte arbejde midlertidigt, arbejde på fejlen og komme tilbage til arbejdet med den nye funktion eller forbedring. Git stash giver en løsning på dette. Du kan nemt skifte kontekst for at foretage ændringer hurtigt.
Eksempel 1 :Antag, at du arbejder på en opgave, der er tildelt dig, og når du ser på status, viser det, at den ikke er sporet lige nu.
Pludselig tildeles der en bug med høj prioritet til dig. Derfor er vi nødt til midlertidigt at gemme eller opbevare det arbejde, der i øjeblikket arbejdes med.
Kør følgende kommando.
git stash gem 'Besked'
I øjeblikket er arbejdsmappen ren. Eventuelle nye forpligtelser kan foretages, og hvis der er fejl, kan du skifte gren for at arbejde på det osv.
Brug kommandoen, når du vil anvende ændringerne igen, hvor du havde forladt.
git stash pop
Ovenstående kommando fjerner stash fra listen og anvender den sidst gemte tilstand.
Du kan også bruge:
git stash gælder
Ovenstående kommando bevarer ændringerne i stash og fjerner dem ikke.
Nu anvendes ændringerne igen, og du kan begå ændringerne.
Eksempel 2: Stash dine ændringer, skift gren og flet ændringer.
Foretag ændringen af Html-filen i mestre gren- og stashændringer.
Næste er at skifte til insekt filial, foretag ændringer og begå ændringer.
git checkout -b bug
Foretag ændringer i HTML-filen.
git commit -a -m “Fixed email issue”
Skift tilbage til mestre gren og genanvend ændringer fra stash.
Nu fusionere fra insekt gren til mestre afdeling. Foretag ændringerne efter fusionen.
Eksempel 3: Arbejde med flere stash.
I den lokale repo er der 2 Html-filer. Så det er muligt, at flere udviklere vil arbejde på flere filer og stash ændringer efter behov for at arbejde på presserende anmodninger, der kommer deres vej til at rette ændringerne.
Udvikler 1 fungerer på hello.html og udvikler 2 fungerer på index.html.
Udvikler 1
Stash-listen har 1 post nu.
Udvikler 2
Stash-listen har nu 2 poster. Den seneste stash er først i stakken, som er stash @ {0}. Nu kan begge udviklerne hurtigst muligt udføre andre forpligtelser eller arbejde på en anden gren og derefter komme tilbage til mestre forgren og anvend stashændringerne.
For at anvende den seneste stash kan du bare køre
git stash pop
For at anvende et specifikt stash i stakken skal du køre følgende kommando.
git stash pop stash @ {1}
Lad os anvende det andet stash, som er stash @ {1}
Tilsvarende kan det andet stash anvendes.
Git Cherry Pick
I dag arbejder udviklerne på flere grene som funktion, forbedring, fejl osv.
Der er situationer, hvor kun et par specifikke forpligtelser skal vælges og ikke flette hele filialen til en anden gren. Dette kaldes en Cherry Pick. Denne proces giver dig mulighed for vilkårligt at vælge enhver Git-forpligtelse fra de andre grene og føje den til det aktuelle HEAD for arbejdstræet.
Eksempel 1:
I det lokale git-arkiv har vi følgende 6 filer.
Én fil slettes, siger fil5.txt.
Foretag ændringerne.
Se på loggen nu. File5.txt slettes.
Så vi vil Cherry-Pick forpligtelsen, hvor vi tilføjede file5.txt. Vi er nødt til at finde kommit-id for file5.tx og køre kommandoen.
git cherry-pick
I dette tilfælde er kommitterings-id'et for hvornår file5.txt blev tilføjet a2f0124
File5.txt gendannes nu. Vi Cherry-Pick forpligtelsen.
Eksempel 2:
Lad os bare ændre det file6.txt og begå ændringer i mestre afdeling.
Se på anden linje ind file6.txt hvor e-mailen ikke er angivet korrekt.
Opret en bugfilial, og løs problemet. På samme tid kan du også ændre file5.txt, så vi har flere forpligtelser udført i buggrenen, men Cherry-Pick kun den forpligtelse, der er udført i file6.txt.
File6 ændret i insekt afdeling.
Så generelt har vi foretaget ændringer til file5 og file6 i buggrenen.
Lad os nu skifte tilbage til mestre filial og Cherry-Pick kun udførelsen til file6.txt.
Som du kan se, i stedet for at flette insekt gren ind i mestre gren, vi har lige Cherry-Picked kun en bestemt forpligtelse og anvendt i mastergrenen.
Git Reset
Git reset er en kraftig kommando til at fortryde lokale ændringer. Så for at fjerne scenen bruges alle de iscenesatte filer, denne kommando.
Eksempel
Rediger en fil, og tilføj den til iscenesættelsen. Nulstil ved hjælp af kommandoen som vist, når de iscenesatte ændringer ikke er iscenesat.
Parametre for git reset kommando.
-blød: Denne parameter peger HEAD til en anden forpligtelse. Alle filer skiftes mellem den oprindelige HEAD og forpligtelsen vil blive iscenesat. Arbejdsmappen er intakt.
Se på den aktuelle HEAD-placering.
Lad os gå tilbage 5 forpligtelser i historien.
Foretag ændringerne igen.
–Blandet: Indstillingen svarer til den bløde parameter. Normalt, når der er nogle dårlige forpligtelser, fjerner du dem og retter det senere og forpligter det tilbage. Så i det væsentlige skal vi tilføje til indeks ved hjælp af git add og så git begå. Ændringer er tilbage i arbejdstræet.
Lad os gå tilbage to forpligtelser i historien og se, at filerne ikke spores.
Føj nu filerne til iscenesættelse og begå ændringerne.
-svært: Denne parameter hviler til et punkt, hvor en bestemt fil eksisterede. Ændringerne vil ikke være tilgængelige i arbejdstræet.
Når man ser på ovenstående log, kan vi gå tilbage til det punkt, hvor kun fil 1 blev begået, dvs. den sidste post.
Ved brug af git reset – hårdt
Git Bisect
Find den nøjagtige forpligtelse, der brød koden (Vi er trods alt alle mennesker). Ofte under test af applikationen hører vi fra vores testere, at der er en fejl, eller at funktionen er brudt, og du som udvikler vil sige, at det fungerede i sidste uge. Så hvad skete der, og hvorfor dukkede denne fejl op?
Nogle gange kan en ændring i den anden kode have påvirket din funktion. Du er nødt til at bruge tid på at gennemgå historien, hvor der er mange forpligtelser, der er tidskrævende og svært at spore, hvilken ændring, der fik koden til at bryde.
Git Bisect er kommandoen til at finde den nøjagtige begivenhed, da fejlen blev introduceret. Med Git bisect skal du vælge to forpligtelser, en god og en dårlig. Cirka halvvejs mellem begge forpligtelser tjekkes ud. Du kontrollerer hver forpligtelse enten dårlig eller god, indtil den forpligtelse, der fik fejlen eller koden til at bryde, er fundet.
Eksempel:
- Opret et nyt lokalt git-arkiv, og opret en fil, der hedder index.html
- Oprindeligt indhold af filen som vist.
- Føj til iscenesættelse og forpligt dig til lageret.
- Opret en historie med forpligtelser som vist, så vi kan vælge mellem gode og dårlige forpligtelser. Når den oprindelige forpligtelse er færdig, skal du foretage de andre ændringer som vist og begå det samme. Samlet set vil vi udføre 7 forpligtelser.
Anden ændring
Tredje ændring
Fjerde ændring
Femte ændring
Sjette ændring
Syvende ændring
Lad os stoppe her. Så vi har syv forpligtelser.
Hvis du ser på HTML-siden, er linjerne efter “Alle de 4 begivenheder…” forkert, og dokumentationen er således ikke korrekt. Så vi er nødt til at finde den forpligtelse, hvor fejlen blev introduceret, så vi kan hvile vores HOVED til denne begåelse.
Lad os se på logfilen og finde ud af dårligt og god begå.
Den seneste forpligtelse er ikke korrekt, så det kan være en dårlig forpligtelse. Forpligtelsen blev indført efter den tredje forpligtelse, så vi kan få den Tredje ændring som de gode begår.
Processen med halvering starter med git bisect start og slutter med git bisect reset.
git halveret dårligt // Da den seneste forpligtelse er dårlig. Ingen grund til at angive kommit-id'et.
git halveret godt
Du kan nu se, at HEAD nu er mellem halvdelen af den dårlige og gode forpligtelse.
Se på indholdet af index.html og se om der er en god forpligtelse. Hvis ikke, er fejlen stadig ikke fundet.
Ikke rigtig, at fejlen stadig eksisterer. Den sidste linje er forkert. Så vi løber ' git bisect bad ’. Der er stadig en dårlig forpligtelse, og det aktuelle indhold er ikke acceptabelt.
Ovenstående indhold er korrekt og acceptabelt.
Kør 'git log –oneline' og 'git bisect good'.
Så Femte ændring var den første dårlige forpligtelse og virkelig. Fejlen er identificeret.
Det aktuelle indhold skal være i den endelige dokumentation.
Da den dårlige forpligtelse identificeres, kan du informere udvikleren om at rette de ændringer, der kan være for at nulstille hovedet til den fjerde ændring, som var den sidste gode forpligtelse.
Løb ' git bisect reset For at afslutte processen.
Konklusion
I denne GitHub hands-on primer har vi forsøgt at dække alt det, som en udvikler har brug for at arbejde på, dvs. fra versionskontrol og sporingsperspektiv.
I de første tre tutorials i GitHub-serien har vi lært om versionskontrolaktiviteter, oprettelse af arkiver, pull-anmodning, filialer, kodevurderinger, organisationer og teams, fork et lager, etiketter, milepæle, udgaver, projektforretninger, wikier, udgivelser, integration med Jira og nogle almindeligt anvendte Git-kommandoer til udviklere.
Vi håber virkelig, at alle udviklerne finder denne praktiske tilgang til GitHub, og Git-kommandoerne er nyttige i deres projekter.
=> Læs gennem Easy GitHub Training Series.
Anbefalet læsning
- GitLab Jira Integrationsvejledning
- Unix-kommandoer: Grundlæggende og avancerede Unix-kommandoer med eksempler
- Selenintegration med GitHub ved hjælp af formørkelse
- JIRA og SVN Integration Tutorial
- Git vs GitHub: Udforsk forskellene med eksempler
- Agurk Selen Tutorial: Agurk Java Selen WebDriver Integration
- GitHub-vejledning til udviklere | Sådan bruges GitHub
- Unix Pipes Tutorial: Rør i Unix-programmering