Introduktion till Git Tag
Innan jag går in på detaljerna i Git Checkout-taggen, låt mig ge dig en kort introduktion till Git och varför den är så populär och användbar. Git är ett verktyg för distribuerad kontroll som inte bara används av produktchefer och utvecklare utan också datavetare för att hantera programmets källkodutveckling och dess historia. I den här artikeln får vi veta mer om Gits koncept för taggning och hur och när kommandot git används.
Vad är Git Tag?
Taggar är referenser som pekar på vissa speciella punkter i Git-historien. Det används främst för att snapshota en viss punkt i det förflutna och för att markera versionen av utgåvan (t.ex. v0.0.1). Det är som en gren som inte förändras. De har inte heller en extra historia av åtaganden. Låt oss börja med att lära oss att skapa nya taggar.
Skapa nya taggar
För att skapa en ny tagg kan du köra följande kommando:
git tag
För att skapa en ny tagg, byt ut med en syntaktiskt liknande identifierare som identifierar sig till förvarets punkt när du skapar taggen. En vanlig metod är att använda versionnummer som git tag v2.5. Git har huvudsakligen två typer av taggar - lätta taggar och annoterade taggar. Ovanstående exempel var av en lätt tagg. Annoterade taggar och lätta taggar är olika med avseende på den totala mängden metadata som de kan lagra med den tidigare som lagrar mer data som består av e-post, datum och taggnamn. De tidigare taggarna är offentliga medan de senare är privata. Lättvikta taggar är precis som "bokmärken" att begå, i princip ett namn som pekar på ett engagemang och därför kan vara användbart för att skapa snabblänkar för relaterade åtaganden.
Kommandona för att skapa en lätt tagg och en kommenterad tagg är respektive:
git tag
git tag -a
Lista taggar
För att lista de lagrade taggarna i en repo kan följande kommando användas:
git tag
Detta ger listan med taggar som utgång:
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
För att få en specifik lista med taggar -l kan vidarebefordras till kommandot tillsammans med ett wild card-uttryck:
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
Exemplet ovan visar användningen av -l-alternativet och ett vildkortsuttryck av -RC som returnerar en lista över alla taggar med specifikationerna angivna mönster markerade med det prefixet, tidigare använt för att känna igen frisläpparkandidater.
Kassa Tagg
Säg att du har ett projekt och att du vill märka specifika punkter på det. För att kolla in en tagg ska den finnas lokalt i ditt förvar. För det måste du hämta alla taggar till ditt lokala arkiv.
git fetch –all eller git fetch --all --tags –prune
När du har hämtat alla taggar kan du kolla in en tagg med kommandot.
git tag -a -m
Och om du efter en tid vill gå med den taggen måste du först göra dina aktuella ändringar för att se till att du är fri att kolla in nya aktiviteter utan att förlora det tidigare arbetet. Detta görs genom att använda:
git checkout tags/
Du kan också skapa en ny gren samtidigt medan du kolla in den här taggen, så att den nuvarande grenen inte skrivs över. Nedanstående kommando används för det.
git checkout tags/ -b
För att lämna den nuvarande grenen kan du gå tillbaka till en annan gren genom att utfärda detta kommando.
git checkout
Lägg märke till att för att byta till en annan gren behöver du bara ange den grenens namn, till skillnad från taggar där du måste infoga prefixet 'taggar /'.
Kommandot git-utcheckning kan användas för att se tillståndet för ett förvar som visas nedan:
git checkout v1.4
Ovannämnda kommando kommer att kolla in v1.4-taggen genom att placera förvaret i en omonterad eller okopplad HEAD, tillståndet som betyder att ingen av de ändringar som gjorts kommer att uppdatera taggen och därmed skapa en ny fristående åtagande. Nu kommer denna nyligen fristående åtagande inte att ingå i någon av de tidigare grenarna och kan därför endast nås direkt av åtagandena. Detta säger oss att det är en utmärkt praxis att spaja en helt ny gren när du vill göra ändringar i ett frånkopplat HEAD-tillstånd.
Om du i ett prov har två taggar som säger version 1.0 och version 1.1, kan du kolla in dem som kör något av följande kommandon:
git checkout B …
git checkout version 1.1 …
git checkout tags/version 1.1 …
Alla ovan nämnda kommandon kommer att göra samma sak som att en tagg bara är en pekare till en given åtagande.
Ta bort taggar
Som namnet antyder används radering av taggar för att radera en specificerad tagg och kan enkelt göras med hjälp av nedanstående kommando.
git tag -d
Om du väljer alternativet -d för att få taggen tillsammans med taggen som ska tas bort kan du ta bort den identifierade taggen.
git tag
v1
v2
v3
git tag -d v1
git tag
v2
v3
I det givna exemplet används först git-taggen för att visa listan med taggar som är v1, v2 och v3. Därefter körs bortkommandot för att radera v1-taggen. Detta tar bort den raderade taggen från servern.
Fördelar med Git Checkout Tag
- Det används för att skapa, ändra och ta bort taggar.
- Det kan användas för att lista alla taggar i det lokala arkivet.
- Det hjälper också till att kassera fjärrgrenar.
- Det hjälper till att hantera och hantera utsläpp.
- Håller förvaret & processen ren och läsbar.
Slutsats - Git Checkout Tag
Git har många användningsområden och används i stor utsträckning av utvecklare, produktchefer och datavetare. Kommandona är mycket effektiva och kan vara mycket användbara. Sammanfattningsvis är taggning en ytterligare mekanism som används för att fånga historien om en Git-repo. Det används traditionellt för att göra semantiska identifieringstaggar som motsvarar versioner av programvaruversioner men det används främst för att skapa, ändra och ta bort taggar.
Rekommenderade artiklar
Detta är en guide till Git Checkout Tag. Här diskuterar vi hur du skapar nya taggar och kolla taggar tillsammans med dess fördelar. Du kan också gå igenom våra andra artiklar som föreslås för att lära dig mer–
- Vad är Git?
- Git-terminologi
- Vad är Git Branch?
- GIT-kommandon
- GIT-versionskontrollsystem
- Git Push
- Tre steg av Git-livscykel med arbetsflödet