Introduksjon til Git Tools

Vi har supereffektive verktøy tilgjengelig med git som kan gjøre vår versjonssporing effektiv, på en måte som gir dypere mening til versjonskontrollsystemet. Disse automatiserte verktøyene vil redde oss fra de fleste av de vanskelige oppgavene og sporing mens vi jobber med grenene.

Noen tilfeller der git-verktøy har hjulpet mye, finner du i detalj nedenfor:

Ulike Git-verktøy

Noen av områdene der git-verktøy kan brukes effektivt:

  • Valg av revisjon
  • Interaktiv iscenesettelse
  • Stashing og rengjøring
  • Signering av arbeidet ditt
  • Verktøy for søk - Grep
  • Omskriv historie
  • Verktøy for avansert fletting
  • Verktøy for feilsøking
  • Git submodule osv

1. Valg av revisjon

Et av de mest effektive verktøyene for å jobbe med forpliktelser. Vi kan følge med på forpliktelser vi har utført og kan henvise dem til å basere kravene våre også. Det er to måter vi kan nå ut til en forpliktelse.

  • Enkelt- eller individuelle forpliktelser
  • Range Commits

Enkelte av individuelle forpliktelser: Hver gang vi begår noe i git, vil tilsvarende SHA - 1-hashnøkkel genereres, og basert på denne nøkkelen kan vi henvise dem til enkle git-show-kommandoer. SHA - 1-tast genereres fra hash-algoritmen som tar innspill og genererer 160-bit eller 20-byte hashverdi

  • Eksempel på skjermbilde kan sees nedenfor der git-loggen presenterer alle ventilene som utføres på grenen og vi kan referere til en spesifikk forpliktelse med den spesielle hasjverdien. Her viser jeg til commit_test2. Vi kan også bruke kortformatnotasjon i showkommando og git vil identifisere nøkkelen og gi dens detaljer. Som nedenfor:

  • På samme måte kan vi bruke flogs og HEAD med git for å få detaljer om hver hendelse som vist på skjermdumpen nedenfor. Den første begivenheten på grenen kalles HEAD eller Master.


Spesifiser områdekommandoer: Vi kan også spesifisere rekkevidekommandoer ved å bruke showkommando. Dette er mest nyttig når vi har flere grener og ønsker å vite hvor de blir slått sammen osv.

  • Fra oven refererer refA til gren A og refB refererer til punkt B. Den første setningen ovenfor representerer engasjementsområdet mellom referansegren A og B, mens det andre begår området som ikke er i området for A og B grener. Den tredje uttalelsen i skjermdumpen ovenfor ligner den andre.

2. Interaktiv iscenesettelse

  • Med et interaktivt iscenesettelsesverktøy kan du spille eller legge mer mening til forpliktelsene dine. Du kan velge hvilke endringer som skal iscenesettes, og hvilke ikke. Dette spesielle verktøyet er nyttig når vi har gjort endringer i en rekke filer, men vi er ikke sikre på noen av endringene. Så i stedet for å begå alt dette interaktive iscenesettelsesverktøyet hjelper det å utføre bare påkrevde filer eller deler i filen ved å bestemme hva som skal iscenesettes og ikke iscenesettes.
  • I skjermbildet nedenfor har vi fire upåførte filer og med interaktiv iscenesettelse ved bruk av git add -I eller git add –interaktive alternativer la jeg bare to filer til iscenesettingen, og de resterende to filene er fremdeles ikke iscenesatt. Så vi kan enkelt begå de iscenesatte filene og fremdeles jobbe med filtreendringer som ikke er iscenesatt og begå senere.
  • Vi må bruke alternativet oppdatering (u eller 2) i det som nå >> blir bedt om o legge til filene i iscenesettelsen.

  • Hvis du observerer det første skjermbildet etter oppdatering >> 2, 3, kan vi se at i 2. og 3. rad * er markert som indikerer valgt fil eller del som skal iscenesettes, og hvis trykk trykker inn igjen vil tesene 2 og 3 bli iscenesatt. I neste engasjement vil de iscenesatte filene bli forpliktet.

  • På samme måte kan vi bruke andre interaktive verktøy som tilbakestilling (3 eller r) for å tilbakestille endringene som er gjort i filen, diff (6 eller d) for å få forskjellen eller modifikasjonen utført i filen som vist på skjermbildet ovenfor. Jeg har brukt diff på news1-filen der rød viser modifikasjonen som er fjernet og i grønt som nylig er lagt til. Tilsvarende kan oppdateringsalternativer brukes til å iscenesette bare deler av en bestemt fil, ikke hele filen.

3. Stashing og rengjøring

  • Noen ganger kan det hende at vi må bytte grenene til å jobbe med noe annet, og vi ønsker ikke å gjøre endringene som er gjort på halvarbeid, men endringene må spores og lagres. Løsningen bruker et git stashing-verktøy. Git stash vil samle alle iscenesatte, sporede filer og steder i en stabel slik at vi kan bruke endringene på nytt når vi vil jobbe med det igjen.
  • Hvis jeg bruker git-status på min nåværende arbeidskatalog, ser det ut som under skjermdump:

  • Her har vi to filer iscenesatt og gjenværende filer er ikke iscenesatt. Nå når jeg bruker git stash, vil alle endringene mine som spores, dvs. iscenesatt og ikke iscenesatt, bli flyttet en minnebunke med stash-ID som vist under skjermdump

  • Når vi bruker stash og git-status, kan vi se at det ikke er noe å forplikte seg på grenen og at alle endringene mine er flyttet. Vi kan se stash-versjonene vi har i minnet med git stash listekommandoen som vist nedenfor.

  • Vi kan ha to versjoner av stash-data lagret i bunken, og vi kan gjenopprette dem igjen ved å bruke git stash Apply-kommando som vil bruke toppstack-stash. Hvis vi ønsker å bruke en bestemt stash, kan vi sende inn det så vel som vist i screengrab nedenfor.

  • Jeg har brukt (0), og filene mine har blitt brukt tilbake. Men det er en stor forskjell da jeg brukte stash back. Du kan se at to av filene mine ble iscenesatt før de satte inn stash, og de ble ikke iscenesatt. Men etter å ha brukt og brukt stashen på nytt, er alle filene mine upålitelig. Stash vil ikke ta vare på filer som er iscenesatt eller ikke iscenesatt. Det legger alt til den uredde staten. Og selv etter at stashen er brukt, vil den forbli i minnet.

  • Vi må eksplisitt nevne git stack drop-kommandoen. Alternativt kan vi også bruke git status pop for å bruke stashen og slippe den en gang.

  • Du kan se ovenfra screengrab at jeg droppet postbeskyttet (0), og i listen kan vi se (1) som jeg hadde tidligere, vil gå tilbake til toppbunken (0)

  • Du kan se bruken av pop-kommando i skjermbildet over der jeg bruker (1) og slipper det på en gang med popkommando. I git stash-listen kunne du se at jeg tidligere har to stash-versjoner, men nå bare en siden andre ble droppet.
  • I likhet med stash som presenterer en ren arbeidskatalog ved å lagre modifiserte filer i stabelen, kan vi også bruke git clean-kommandoen. Men her vil vi ikke være i stand til å redde eller bruke noe tilbake, og vi må være forsiktige og sikre mens vi bruker dette. Det er ofte bedre å foretrekke stash fremfor rent. Det er flere underalternativer også når du bruker git clean som vi kan utforske.

Konklusjon

Dette er noen av verktøyene som har gjort det rotete arbeidet vårt med grenene mye enklere, og det er andre verktøy i tillegg, spesielt som Submodule, Debug, Advanced Merge, osv. Som kan hjelpe oss i forskjellige situasjoner mens vi også jobber med grener.

Anbefalte artikler

Dette er en guide til Git Tools. Her diskuterer vi Various Git Tools i detaljforklaring. Du kan også gå gjennom andre relaterte artikler for å lære mer-

  1. Hva er Git Branch?
  2. Hva er Git?
  3. Git terminologi
  4. GIT-kommandoer
  5. GIT versjonskontrollsystem
  6. Git Push
  7. Tre stadier av Git-livssyklus med arbeidsflyten

Kategori:

Stor Data