Introduksjon til Git Tag
Før jeg går inn på detaljene i Git Checkout Tag, la meg gi deg en kort introduksjon til Git og hvorfor den er så populær og nyttig. Git er et verktøy for distribuert kontroll som ikke bare brukes av produktledere og utviklere, men også dataforskere for å administrere kildekodeutviklingen til programmet og dets historie. I denne artikkelen får vi vite mer om Gits konsept for tagging og hvordan og når git tag-kommandoen brukes.
Hva er Git Tag?
Tagger er referanser som peker på noen spesielle punkter i Git-historien. Det brukes hovedsakelig til å snapshot et bestemt punkt i fortiden og for å merke versjonen av utgivelsen (f.eks. V0.0.1). Det er som en gren som ikke endres. De har heller ikke en ekstra historie med forpliktelser. La oss begynne med å lære å lage nye tagger.
Opprette nye tagger
For å opprette en ny tag kan du utføre følgende kommando:
git tag
For å opprette en ny tag, bytt ut med en syntaktisk identifikator som identifiserer seg til depotpunktet når du oppretter taggen. En vanlig tilnærming er å bruke versjonsnumre som git tag v2.5. Git har hovedsakelig to typer tagger - lette koder og merkede koder. Eksemplet ovenfor hadde en lett tagg. Annoterte tagger og lette tagger er forskjellige med hensyn til den totale mengden metadata de kan lagre med den forrige som lagrer flere data som består av e-post, dato og taggenavn. De førstnevnte kodene er offentlige, mens de sistnevnte er private. Lette tagger er akkurat som 'bokmerker' å begå, i utgangspunktet et navn som peker på en forpliktelse, og derfor kan være nyttige for å lage hurtigkoblinger for relaterte forpliktelser.
Kommandoene for å opprette en lett tagg og en merket tagg er henholdsvis:
git tag
git tag -a
Viser tagger
Følgende kommando kan brukes for å liste de lagrede kodene i en repo:
git tag
Dette gir listen over tagger som utdata:
v1.12.0
v1.12.0-RC1
v0.13.0
v1.13.0-RC1
v0.13.1
v2.14.0
v0.14.0-RC1
v1.14.2
v0.12.0
v0.12.0-RC1
v1.12.0-RC2
For å få en spesifikk liste med tagger -l kan sendes til kommandoen sammen med et jokertekstuttrykk:
git tag -l *-RC*
v0.12.0-RC1
v1.13.0-RC1
v0.14.0-RC1
v2.14.0-RC2
v0.15.0-RC1
v1.10.0-RC1
v14.0.0-rc.2
v14.5.0-rc.3
Eksemplet ovenfor viser bruken av -l-alternativet og et jokerkortuttrykk for -RC som returnerer en liste over alle kodene med spesifikasjonene gitt mønster merket med det prefikset, tidligere brukt til å gjenkjenne utgivelseskandidater.
Kassa
Si at du har et prosjekt, og at du vil merke bestemte punkter på det. For å sjekke en kode, bør den være lokalt til stede i depotet ditt. For det må du hente alle kodene til det lokale depotet ditt.
git fetch –all eller git fetch --all --tags –prune
Etter å ha hentet alle kodene, kan du sjekke ut en kode ved hjelp av kommandoen.
git tag -a -m
Og hvis du etter en tid ønsker å gå med den taggen, må du først forplikte dine nåværende endringer for å sikre at du står fritt til å sjekke ut nye aktiviteter uten å miste det tidligere arbeidet. Dette gjøres ved å bruke:
git checkout tags/
Du kan også opprette en ny gren samtidig mens du sjekker ut denne taggen, slik at den nåværende grenen ikke blir overskrevet. Den gitte kommandoen nedenfor brukes til det.
git checkout tags/ -b
For å avslutte den nåværende grenen kan du gå tilbake til en annen gren ved å utgi denne kommandoen.
git checkout
Legg merke til at for å bytte til en annen gren, må du bare oppgi navnet på grenen, i motsetning til med koder der du må sette inn prefikset 'koder /'.
Kommandoen git checkout kan brukes til å se tilstanden til et depot som vist nedenfor:
git checkout v1.4
Ovennevnte kommando vil sjekke ut v1.4-taggen ved å plassere depotet i en umontert eller frakoblet HEAD, staten som betyr at ingen av endringene som blir gjort vil oppdatere koden og dermed opprette en ny løsrevet begrep. Nå vil ikke denne nylig frittliggende forpliktelsen være en del av noen av de tidligere grenene, og kan derfor bare nås direkte av forpliktelsene. Dette forteller oss at det er en utmerket praksis å gyte en helt ny gren når du vil gjøre endringer i en frakoblet HEAD-tilstand.
Hvis du i en prøve har to tagger som sier versjon 1.0 og versjon 1.1, kan du sjekke ut dem som utfører en av følgende kommandoer:
git checkout B …
git checkout version 1.1 …
git checkout tags/version 1.1 …
Alle de ovennevnte kommandoene vil gjøre det samme som en tag er bare en peker til en gitt forpliktelse.
Slette tagger
Som navnet antyder, blir sletting av tagger brukt til å slette en spesifisert kode, og det kan enkelt gjøres ved å bruke den under-nevnte kommandoen.
git tag -d
Ved å omgå alternativet -d for å gi tag sammen med taggen som skal slettes, kan du slette den identifiserte koden.
git tag
v1
v2
v3
git tag -d v1
git tag
v2
v3
I det gitte eksemplet blir git-taggen først brukt til å vise listen over tagger som er v1, v2 og v3. Deretter utføres slettekommandoen for å slette v1-taggen. Dette fjerner den slettede taggen fra serveren.
Fordeler med Git Checkout Tag
- Den brukes til å opprette, endre og slette koder.
- Den kan brukes til å liste alle kodene i det lokale depotet.
- Det hjelper også til å sjekke eksterne grener.
- Det hjelper deg med å administrere og håndtere utgivelser.
- Holder depotet og prosessen ren og lesbar.
Konklusjon - Git Checkout Tag
Git har mange bruksområder og blir mye brukt av utviklere, produktledere og dataforskere. Kommandoene er veldig effektive og kan være veldig nyttige. For å oppsummere, er tagging en ekstra mekanisme som brukes til å fange historien til en Git-repo. Det brukes tradisjonelt til å lage semantiske identifikasjonsmerker som samsvarer med versjonsutgivelsesversjoner, men de brukes hovedsakelig til å opprette, endre og slette koder.
Anbefalte artikler
Dette er en guide til Git Checkout Tag. Her diskuterer vi hvordan du oppretter nye tagger og sjekker ut tagger sammen med fordelene. Du kan også gå gjennom de andre foreslåtte artiklene våre for å lære mer–
- Hva er Git?
- Git terminologi
- Hva er Git Branch?
- GIT-kommandoer
- GIT versjonskontrollsystem
- Git Push
- Tre stadier av Git-livssyklus med arbeidsflyten