Svenska ▾ Topics ▾ Latest version ▾ git-tag last updated in 2.52.0

NAMN

git-tag - Skapa, lista, ta bort eller verifiera taggar

SYNOPSIS

git tag [-a | -s | -u <nyckel-id>] [-f] [-m <medd> | -F <fil>] [-e]
	[(--trailer <token>[(=|:)<värde>])…​]
	<taggnamn> [<incheckning> | <objekt>]
git tag -d <taggnamn>…​
git tag [-n[<num>]] -l [--contains <incheckning>] [--no-contains <incheckning>]
	[--points-at <objekt>] [--column[=<flaggor>] | --no-column]
	[--create-reflog] [--sort=<nyckel>] [--format=<format>]
	[--merged <incheckning>] [--no-merged <incheckning>] [<mönster>…​]
git tag -v [--format=<format>] <taggnamn>…​

BESKRIVNING

Lägg till en taggreferens i refs/tags/, såvida inte -d/-l/-v anges för att ta bort, lista eller verifiera taggar.

Om inte -f anges får den namngivna taggen inte existera ännu.

Om något av -a, -s eller -u <nyckel-id> skickas, skapar kommandot ett tag-objekt och kräver ett taggmeddelande. Om inte -m <medd> eller -F <fil> anges, startas en redigerare där användaren kan skriva in taggmeddelandet.

Om -m <medd> eller -F <fil> eller --trailer <token>[=<värde>] anges och -a, -s och -u <nyckel-id> saknas, är -a underförstått.

Annars skapas en taggreferens som pekar direkt mot det givna objektet (d.v.s. en lättviktstagg).

Ett kryptografiskt signerat taggobjekt skapas när -s eller -u <nyckel-id> används. Signeringsbakendan (GPG, X.509, SSH, etc.) styrs av konfigurationsvariabeln gpg.format, som standard är OpenPGP. När -u <nyckel-id> inte används incheckarens-identitet för den aktuella användaren för att hitta nyckeln för signering. Konfigurationsvariabeln gpg.program används för att ange en anpassad signeringsbinärfil.

Taggobjekt (skapade med -a, -s eller -u) kallas "kommenterade" taggar; de innehåller ett skapandedatum, taggarens namn och e-postadress, ett taggmeddelande och en valfri kryptografisk signatur. Medan en "lätt" tagg helt enkelt är ett namn för ett objekt (vanligtvis ett incheckningsobjekt).

Annoterade taggar är avsedda för publicering medan lättviktstaggar är avsedda för privata eller tillfälliga objektetiketter. Av denna anledning kommer vissa git-kommandon för att namnge objekt (som git describe) att ignorera lättviktstaggar som standard.

ALTERNATIV

-a
--annotate

Skapa ett osignerat, kommenterat taggobjekt

-s
--sign

Skapa en kryptografiskt signerad tagg med standardsigneringsnyckeln. Vilken signeringsbakände som används beror på konfigurationsvariabeln gpg.format. Standardnyckeln bestäms av bakänden. För GPG baseras den på incheckarens e-postadress, medan den för SSH kan vara en specifik nyckelfil eller agentidentitet. Se git-config[1].

--no-sign

Åsidosätt konfigurationsvariabeln tag.gpgSign som är inställd på att tvinga varje tagg att signeras.

-u <nyckel-id>
--local-user=<nyckel-id>

Skapa en kryptografiskt signerad tagg med den givna nyckeln. Formatet för <nyckel-id> och vilken bakände som används beror på konfigurationsvariabeln gpg.format. Se git-config[1].

-f
--force

Ersätt en befintlig tagg med det angivna namnet (i stället för att misslyckas)

-d
--delete

Ta bort befintliga taggar med de angivna namnen.

-v
--verify

Verifiera den kryptografiska signaturen för de angivna taggarna.

-n<num>

<num> anger hur många rader från annoteringen, om några, som skrivs ut när -l används. Innebär --list.

Standardinställningen är att inga anteckningsrader skrivs ut. Om inget nummer anges till -n skrivs endast den första raden ut. Om taggen inte är annoterad visas incheckningsmeddelandet i stället.

-l
--list

Lista taggar. Med valfritt <mönster>..., t.ex. git tag --list v-*', lista endast de taggar som matchar mönstret/mönstren.

Om git tag körs utan argument listas även alla taggar. Mönstret är ett skaljokertecken (d.v.s. matchat med fnmatch(3)). Flera mönster kan anges; om något av dem matchar visas taggen.

Det här alternativet tillhandahålls implicit om något annat listliknande alternativ, såsom --contains, tillhandahålls. Se dokumentationen för vart och ett av dessa alternativ för mer information.

--sort=<nyckel>

Sortera baserat på den angivna nyckeln. Prefixet - för att sortera i fallande ordning efter värdet. Du kan använda alternativet --sort=<nyckel> flera gånger, i vilket fall den sista <nyckel>n blir primärnyckeln. Stöder även "version:refname" eller "v:refname" (taggnamn behandlas som versioner). Sorteringsordningen "version:refname" kan också påverkas av konfigurationsvariabeln "versionsort.suffix". Nycklarna som stöds är desamma som i git for-each-ref. Sorteringsordningen är som standard det värde som konfigurerats för variabeln tag.sort om den finns, eller lexikografisk ordning annars. Se git-config[1].

--color[=<när>]

Respektera alla färger som anges i alternativet --format. Fältet <när> måste vara ett av always, never eller auto (om <när> saknas, bete sig som om always hade angetts).

-i
--ignore-case

Sorterings- och filtreringstaggar är skiftlägesoberoende.

--omit-empty

Skriv inte ut en nyrad efter formaterade referenser där formatet expanderar till den tomma strängen.

--column[=<alternativ>]
--no-column

Visa tagglistan i kolumner. Se konfigurationsvariabeln column.tag för alternativsyntax. --column och --no-column utan alternativ motsvarar always respektive never.

Det här alternativet gäller endast när taggar listas utan annoteringsrader.

--contains [<incheckning>]

Lista endast taggar som innehåller <incheckning> (HEAD om inget anges). Innebär --list.

--no-contains [<incheckning>]

Lista endast taggar som inte innehåller <incheckning> (HEAD om inget anges). Innebär --list.

--merged [<incheckning>]

Lista endast taggar vars incheckningar är nåbara från <incheckning> (HEAD om inget anges).

--no-merged [<incheckning>]

Lista endast taggar vars incheckningar inte kan nås från <incheckning> (HEAD om inget anges).

--points-at [<objekt>]

Lista endast taggar för <objekt> (HEAD om inget anges). Innebär --list.

-m <medd>
--message=<medd>

Använd <medd> (i stället för att fråga). Om flera -m-alternativ anges sammanfogas deras värden som separata stycken. Innebär -a om inget av -a, -s eller -u <nyckel-id> anges.

-F <fil>
--file=<fil>

Ta taggmeddelandet från <fil>. Använd - för att läsa meddelandet från standardindata. Innebär -a om ingen av -a, -s eller -u <nyckel-id> anges.

--trailer <token>[(=|:)<värde>]

Ange ett (<token>, <värde>)-par som ska användas som en trailer. (t.ex. git tag --trailer "Custom-Key: value" lägger till en "Custom-Key"-slutrad i taggmeddelandet.) Konfigurationsvariablerna trailer.* (git-interpret-trailers[1]) kan användas för att definiera om en duplicerad slutrad utelämnas, var i slutradserien varje slutrad ska visas och andra detaljer. slutraderna extraheras i git tag --list med hjälp av platshållaren --format="%(trailers)".

-e
--edit

Låt oss redigera meddelandet som hämtats från filen ytterligare med -F och kommandoraden med -m.

--cleanup=<läge>

Ställ in hur taggmeddelandet ska rensas. <läge> kan vara ett av verbatim, whitespace eller strip. Strip-läget är standard. verbatim-läget ändrar inte meddelandet alls, whitespace tar bara bort inledande/efterföljande blankstegsrader och strip tar bort både blanksteg och kommentarer.

--create-reflog

Skapa en reflog för taggen. För att globalt aktivera refloggar för taggar, se core.logAllRefUpdates i git-config[1]. Den negerade formen --no-create-reflog åsidosätter endast en tidigare --create-reflog, men negerar för närvarande inte inställningen för core.logAllRefUpdates.

--format=<format>

En sträng som interpolerar %(fieldname) från en taggreferens som visas och objektet den pekar på. Formatet är detsamma som för git-for-each-ref[1]. Om den inte är angiven används %(refname:strip=2) som standard.

<taggnamn>

Namnet på taggen som ska skapas, tas bort eller beskrivas. Det nya taggnamnet måste klara alla kontroller som definieras av git-check-ref-format[1]. Vissa av dessa kontroller kan begränsa tecken som är tillåtna i ett taggnamn.

<incheckning>
<objekt>

Objektet som den nya taggen ska referera till, vanligtvis en incheckning. Standardvärdet är HEAD.

KONFIGURATION

Som standard använder git tag i sign-with-default-läge (-s) din incheckare-identitet (i formen Ditt namn <din@e-postadress>) för att hitta en nyckel. Om du vill använda en annan standardnyckel kan du ange den i kodförrådskonfigurationen enligt följande:

[user]
    signingKey = <nyckel-id>

Signeringsbakänden kan väljas via konfigurationsvariabeln gpg.format, som standard används openpgp. Se git-config[1] för en lista över andra format som stöds.

Sökvägen till programmet som används för varje signeringsbakände kan anges med konfigurationsvariabeln gpg.<format>.program. För openpgp-bakänden kan gpg.program användas som en synonym för gpg.openpgp.program. Se git-config[1] för detaljer.

pager.tag respekteras bara när taggar listas, d.v.s. när -l används eller antyds. Standardinställningen är att använda en bläddrare.

Se git-config[1] för mer information och andra konfigurationsvariabler.

DISKUSSION

Om omtaggning

Vad ska du göra när du taggar en fel incheckning och vill tagga om?

Om du aldrig har publicerat något, tagga det bara om. Använd -f för att ersätta det gamla. Och du är klar.

Men om du har skickat ut saker (eller om andra bara kan läsa ditt kodförråd direkt), så har andra redan sett den gamla taggen. I så fall kan du göra en av två saker:

  1. Det vettiga. Erkänn bara att du misslyckades och använd ett annat namn. Andra har redan sett ett taggnamn, och om du behåller samma namn kan du hamna i situationen att två personer båda har "version X", men de har faktiskt "olika" "X". Så kalla det bara "X.1" och var klar med det.

  2. Det galna. Du vill verkligen kalla den nya versionen för "X" också, "även om" andra redan har sett den gamla. Så använd bara git tag -f igen, som om du inte redan hade publicerat den gamla.

Git ändrar dock inte (och borde inte) taggar bakom användarnas rygg. Så om någon redan har fått den gamla taggen, borde en git pull på ditt träd inte bara få dem att skriva över den gamla.

Om någon fick en release-tagg från dig, kan du inte bara ändra taggen för dem genom att uppdatera din egen. Detta är ett stort säkerhetsproblem, eftersom folk MÅSTE kunna lita på deras taggnamn. Om du verkligen vill göra den galna grejen måste du bara erkänna det och berätta för folk att du gjorde fel. Du kan göra det genom att göra ett mycket offentligt tillkännagivande som säger:

Okej, jag gjorde ett misstag och publicerade en tidigare version taggad som X.
Sedan fixade jag något, och taggade om det *fixade* trädet till X igen.

Om du fick fel tagg och vill ha den nya, vänligen radera
den gamla och hämta den nya genom att göra:

	git tag -d X
	git fetch origin tag X

för att få min uppdaterade tagg.

Du kan testa vilken tagg du har genom att göra

	git rev-parse X

vilket borde returnera 0123456789abcdef.. om du har den nya versionen.

Ursäkta besväret.

Verkar det här lite komplicerat? Det borde det vara. Det finns inget sätt att det skulle vara korrekt att bara "fixa" det automatiskt. Folk behöver veta att deras taggar kan ha ändrats.

På automatisk efterföljning

Om du följer någon annans träd, använder du troligtvis grenar för fjärrspårning (t.ex. refs/remotes/origin/master). Du vill vanligtvis ha taggarna från andra änden.

Å andra sidan, om du hämtar information för att du vill ha en engångssammanslagning från någon annan, vill du vanligtvis inte få taggar därifrån. Detta händer oftare för personer nära toppnivån, men inte begränsat till dem. Vanliga dödliga vill inte nödvändigtvis automatiskt få privata ankarpunktstaggar från den andra personen när de drar in ("hämta") information från varandra.

Ofta, innehåller "please pull"-meddelanden på e-postlistan bara två uppgifter: en kodförråd-URL och ett grennamn; detta är utformat för att enkelt kunna klippas ut och klistras in i slutet av en git fetch-kommandorad:

Linus, please pull from

	git://git..../proj.git master

för att få följande uppdateringar...

blir:

$ git pull git://git..../proj.git master

I ett sådant fall, vill du inte automatiskt följa den andra personens taggar.

En viktig aspekt av Git är dess distribuerade natur, vilket till stor del innebär att det inte finns någon inneboende "uppströms" eller "nedströms" i systemet. Vid första anblicken kan exemplet ovan verka indikera att taggnamnrymden ägs av den övre skiktet av människor och att taggar bara flödar nedåt, men så är inte fallet. Det visar bara att användningsmönstret avgör vem som är intresserad av vems taggar.

En engångs-pull är ett tecken på att en incheckningshistorik nu överskrider gränsen mellan en krets av personer (t.ex. "personer som främst är intresserade av nätverksdelen av kärnan") som kan ha sin egen uppsättning taggar (t.ex. "detta är den tredje releasekandidaten från nätverksgruppen som föreslås för allmän konsumtion med 2.6.21-utgåvan") till en annan krets av personer (t.ex. "personer som integrerar olika delsystemförbättringar"). De senare är vanligtvis inte intresserade av de detaljerade taggar som används internt i den förra gruppen (det är vad "intern" betyder). Det är därför det är önskvärt att inte följa taggar automatiskt i detta fall.

Det kan mycket väl vara så att nätverks-folket vill utbyta taggar internt i sin grupp, men i det arbetsflödet spårar de troligtvis varandras framsteg genom att ha grenar för fjärrspårning. Återigen är heuristiken att automatiskt följa sådana taggar en bra sak.

Om bakdaterings-taggar

Om du har importerat några ändringar från en annan VCS och vill lägga till taggar för större utgåvor av ditt arbete är det bra att kunna ange datumet för inbäddning i taggobjektet; sådan data i taggobjektet påverkar till exempel ordningen på taggar i gitweb-gränssnittet.

För att ställa in datumet som ska användas i framtida taggobjekt, ange miljövariabeln GIT_COMMITTER_DATE (se den senare diskussionen om möjliga värden; den vanligaste formen är "YYYY-MM-DD HH:MM").

Till exempel:

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

DATUMFORMAT

Miljövariablerna GIT_AUTHOR_DATE och GIT_COMMITTER_DATE stöder följande datumformat:

Git internt format

Det är <unix-timestamp> <time-zone-offset>, där <unix-timestamp> är antalet sekunder sedan UNIX-epoken. <time-zone-offset> är en positiv eller negativ förskjutning från UTC. Till exempel är CET (som är 1 timme före UTC) +0100.

RFC 2822

Standarddatumformatet som beskrivs av RFC 2822, till exempel Tor, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Tid och datum som anges av ISO 8601-standarden, till exempel 2005-04-07T22:13:13. Parsern accepterar även ett mellanslag istället för tecknet T. Bråkdelar av en sekund kommer att ignoreras, till exempel 2005-04-07T22:13:13.019 kommer att behandlas som 2005-04-07T22:13:13.

Note
 Dessutom accepteras datumdelen i följande format: ÅÅÅÅ.MM.DD, MM/DD/ÅÅÅÅ och DD.MM.ÅÅÅÅ.

FILER

$GIT_DIR/TAG_EDITMSG

Den här filen innehåller meddelandet om en kommenterad tagg som pågår. Om git tag avslutas på grund av ett fel innan en kommenterad tagg skapas, kommer taggmeddelandet som har angetts av användaren i en redigerings-session att finnas tillgängligt i den här filen, men kan skrivas över av nästa anrop av git tag.

KONFIGURATION

Allt under den här raden i det här avsnittet är selektivt inkluderat från dokumentationen git-config[1]. Innehållet är detsamma som det som finns där:

tag.forceSignAnnotated

Ett booleskt värde som anger om skapade annoterade taggar ska vara GPG-signerade. Om --annotate anges på kommandoraden har det företräde framför detta alternativ.

tag.sort

Denna variabel styr sorteringsordningen för taggar när de visas av git-tag. Utan alternativet --sort=<value> anges, kommer värdet på denna variabel att användas som standard.

tag.gpgSign

En booleskt värde som anger om alla taggar ska GPG-signeras. Användning av det här alternativet när du kör i ett automatiserat skript kan resultera i att ett stort antal taggar signeras. Det är därför bekvämt att använda en agent för att undvika att skriva in din GPG-lösenfras flera gånger. Observera att det här alternativet inte påverkar taggsigneringsbeteendet som aktiveras av alternativen -u <keyid> eller --local-user=<keyid>.

NOTERINGAR

När man kombinerar flera --contains- och --no-contains-filter visas endast referenser som innehåller minst en av --contains-commits och inte innehåller någon av --no-contains-incheckningar.

När man kombinerar flera --merged- och --no-merged-filter visas endast referenser som är nåbara från minst en av --merged-commits och från ingen av --no-merged-incheckningar.

SE ÄVEN

git-check-ref-format[1]. git-config[1].

GIT

En del av git[1]-sviten