git-tag - Online în cloud

PROGRAM:

NUME

git-tag - Creați, enumerați, ștergeți sau verificați un obiect etichetă semnat cu GPG

REZUMAT

merge etichetă [-a | -s | -u ] [-f] [-m | -F ]
[ | ]
merge etichetă -d ...
merge etichetă [-n[ ]] -l [--contine ] [--punctează-la ]
[--coloana[= ] | --no-coloană] [--create-reflog] [--sort= ]
[--format= ] [--[no-]fusionat [ ]] [ ...]
merge etichetă -v ...

DESCRIERE

Adăugați o referință de etichetă în refs/tags/, cu excepția cazului în care este dat -d/-l/-v pentru a șterge, lista sau verifica
tag-uri.

Dacă nu este dat -f, eticheta numită nu trebuie să existe încă.

Dacă unul dintre -a, -s sau -u este trecută, comanda creează a etichetă obiect și necesită
un mesaj de etichetă. Cu excepția cazului în care -m sau -F este dat, un editor este pornit pentru utilizator
introduceți mesajul etichetei.

Dacă -m sau -F este dat și -a, -s și -u sunt absente, -a este subînțeles.

În caz contrar, este creată doar o referință de etichetă pentru numele obiectului SHA-1 al obiectului de comitere
(adică o etichetă ușoară).

Un obiect etichetă semnat GnuPG va fi creat când -s sau -u este folosit. Cand tu
nu este folosit, identitatea committer pentru utilizatorul curent este folosită pentru a găsi cheia GnuPG pentru
semnare. Variabila de configurare gpg.program este folosită pentru a specifica binarul GnuPG personalizat.

Obiectele de etichetă (create cu -a, -s sau -u) sunt numite etichete „adnotate”; ele contin a
data creării, numele și e-mailul etichetatorului, un mesaj de etichetare și un GnuPG opțional
semnătură. În timp ce o etichetă „ușoară” este pur și simplu un nume pentru un obiect (de obicei un commit
obiect).

Etichetele adnotate sunt destinate lansării, în timp ce etichetele ușoare sunt destinate private sau
etichete temporare de obiecte. Din acest motiv, unele comenzi git pentru denumirea obiectelor (cum ar fi git
descrie) va ignora implicit etichetele ușoare.

OPŢIUNI

-a, --adnotare
Creați un obiect etichetă nesemnat, adnotat

-s, --semn
Creați o etichetă semnată GPG, folosind cheia implicită a adresei de e-mail.

-u , --local-user=
Faceți o etichetă semnată de GPG, folosind cheia dată.

-f, --forță
Înlocuiți o etichetă existentă cu numele dat (în loc să eșueze)

-d, --delete
Ștergeți etichetele existente cu numele date.

-v, --verify
Verificați semnătura gpg a numelor de etichete date.

-n
specifică câte linii din adnotare, dacă există, sunt tipărite când se utilizează -l.
Valoarea implicită este să nu imprimați nicio linie de adnotare. Dacă nu este dat niciun număr lui -n, numai
se imprimă prima linie. Dacă eticheta nu este adnotată, mesajul de confirmare este
afișat în schimb.

-l , --listă
Listați etichetele cu nume care se potrivesc cu modelul dat (sau toate dacă nu este dat niciun model).
Rularea „git tag” fără argumente listează și toate etichetele. Modelul este o coajă
wildcard (adică, potrivire folosind fnmatch(3)). Pot fi date mai multe modele; dacă vreuna dintre
se potrivesc, se afișează eticheta.

--sort=
Sortați în funcție de cheia dată. Prefix - pentru a sorta în ordinea descrescătoare a valorii. Tu
poate folosi --sort= opțiunea de mai multe ori, caz în care ultima cheie devine
cheia principala. De asemenea, acceptă „version:refname” sau „v:refname” (numele etichetelor sunt tratate ca
versiuni). Ordinea de sortare „version:refname” poate fi, de asemenea, afectată de
Variabila de configurare „versionsort.prereleaseSuffix”. Tastele suportate sunt aceleași
ca cele din git for-each-ref. Ordinea de sortare este implicită la valoarea configurată pentru
tag.sortare variabilă dacă există, sau ordine lexicografică în caz contrar. Vedea git-config(1).

--coloană[= ], --no-coloană
Afișați lista de etichete în coloane. Consultați variabila de configurare column.tag pentru opțiune
sintaxă.--column și --no-column fără opțiuni sunt echivalente cu mereu și nu
respectiv.

Această opțiune este aplicabilă numai atunci când se listează etichete fără linii de adnotare.

--contine [ ]
Listează numai etichetele care conțin commit-ul specificat (HEAD dacă nu este specificat).

--indică-la
Listează numai etichetele obiectului dat.

-m , --message=
Folosiți mesajul de etichetă dat (în loc să solicitați). Dacă sunt date mai multe opțiuni -m,
valorile lor sunt concatenate ca paragrafe separate. Implica -a dacă niciunul dintre -a, -s sau
-u este dată.

-F , --file=
Luați mesajul etichetei din fișierul dat. Utilizare - pentru a citi mesajul din standard
intrare. Implica -a dacă niciunul dintre -a, -s sau -u este dată.

--curățare=
Această opțiune setează modul în care mesajul de etichetă este curățat. The poate fi unul dintre textual,
spatiu alb și strip. strip modul este implicit. The textual modul nu se schimbă
mesaj deloc, spatiu alb elimină doar liniile de spații albe de început/în urmă și strip
elimină atât spațiile albe, cât și comentariile.

--create-reflog
Creați un reflog pentru etichetă.


Numele etichetei de creat, șters sau descris. Noul nume de etichetă trebuie să treacă toate
verificări definite de git-check-ref-format(1). Unele dintre aceste verificări pot restricționa
caractere permise într-un nume de etichetă.

,
Obiectul la care se va referi noua etichetă, de obicei un commit. Setarea implicită este HEAD.


Un șir care interpolează %(fieldname) din obiectul indicat de o ființă ref
afișate. Formatul este același cu cel al git-pentru-fiecare-ref(1). Când nu este specificat,
implicit la %(refname:strip=2).

--[nu-]combinat [ ]
Listați numai etichetele ale căror sfaturi sunt accesibile sau nu sunt accesibile dacă --fără îmbinare este folosit, din
commit-ul specificat (HEAD dacă nu este specificat).

CONFIGURARE

În mod implicit, merge etichetă în modul sign-with-default (-s) va folosi identitatea dvs. de committer (of
formularul Numele tău[e-mail protejat]>) pentru a găsi o cheie. Dacă doriți să utilizați un alt
cheie implicită, o puteți specifica în configurația depozitului, după cum urmează:

[utilizator]
signingKey =

DISCUŢIE

On Reetichetare
Ce ar trebui să faceți când etichetați o comitere greșită și doriți să reetichetați?

Dacă nu ai împins nimic afară, etichetează-l din nou. Folosiți „-f” pentru a-l înlocui pe cel vechi. Și
ați terminat.

Dar dacă ați eliminat lucrurile (sau alții ar putea doar să vă citească direct depozitul),
atunci alții vor fi văzut deja eticheta veche. În acest caz, puteți face unul dintre cele două lucruri:

1. Lucrul sănătos la minte. Doar recunoaște că ai greșit și folosește un alt nume. Alții au
ați văzut deja un nume de etichetă și, dacă păstrați același nume, este posibil să vă aflați în situație
că doi oameni au amândoi „versiunea X”, dar de fapt au diferit „X”. Deci doar
numiți-o „X.1” și gata.

2. Chestia nebunească. Chiar vrei să numi și noua versiune „X”, chiar deşi alţii
l-am văzut deja pe cel vechi. Așa că doar folosește merge etichetă -f din nou, de parcă nu ai fi făcut-o deja
a publicat cel vechi.

Cu toate acestea, Git o face nu (și nu ar trebui) să schimbe etichetele în spatele utilizatorilor. Deci dacă cineva
a primit deja eticheta veche, făcând a merge trage pe arborele tău nu ar trebui să le facă să se suprascrie
cel Bătrân.

Dacă cineva a primit o etichetă de lansare de la tine, nu poți să schimbi eticheta pentru el
actualizarea propriei dvs. Aceasta este o mare problemă de securitate, în sensul că oamenii TREBUIE să poată avea încredere
numele etichetelor lor. Dacă vrei cu adevărat să faci nebunia, trebuie doar să mărturisești
și spune-le oamenilor că ai greșit. Puteți face asta făcând un public foarte public
anunț care spune:

Ok, am greșit și am scos o versiune anterioară etichetată ca X. I
apoi a reparat ceva și a reetichetat arborele *fix* ca X din nou.

Dacă ați greșit eticheta și doriți una nouă, vă rugăm să ștergeți
cel vechi și adu-l pe cel nou făcând:

git tag -d X
git aduce eticheta de origine X

pentru a obține eticheta mea actualizată.

Puteți testa ce etichetă aveți făcând

git rev-parse X

care ar trebui să returneze 0123456789abcdef.. dacă aveți noua versiune.

Ne pare rău pentru neplăcerile create.

Ti se pare un pic complicat? Aceasta să fi. Nu există cum să fie corect
pentru a-l „remedia” automat. Oamenii trebuie să știe că etichetele lor ar fi putut fi
schimbat.

On Automat următor
Dacă urmăriți arborele altcuiva, cel mai probabil utilizați urmărirea de la distanță
ramuri (refs/heads/origine în aspectul tradițional sau refs/remotes/origin/master în
aspect separat-la distanță). De obicei vrei etichetele de la celălalt capăt.

Pe de altă parte, dacă preluați pentru că ați dori o îmbinare unică de la
altcineva, de obicei nu doriți să obțineți etichete de acolo. Acest lucru se întâmplă mai des
pentru persoanele din apropierea nivelului superior, dar fără a se limita la ei. Simpli muritori când trag din fiecare
alții nu doresc neapărat să obțină automat etichete private de puncte de ancorare de la
alta persoana.

Adesea, mesajele „vă rugăm să trageți” de pe lista de corespondență oferă doar două informații:
o adresă URL repo și un nume de sucursală; acesta este conceput pentru a fi tăiat și lipit cu ușurință la sfârșitul a merge
aduc Linie de comanda:

Linus, te rog trage de la

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

pentru a primi următoarele actualizări...

devine:

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

Într-un astfel de caz, nu doriți să urmăriți automat etichetele celeilalte persoane.

Un aspect important al Git este natura sa distribuită, ceea ce înseamnă în mare parte că nu există
inerente „în amonte” sau „în aval” în sistem. Pe față, exemplul de mai sus
ar putea părea să indice că spațiul de nume etichete este deținut de eșalonul superior al oamenilor și
că etichetele curg doar în jos, dar nu este cazul. Arată doar că utilizarea
modelul determină cine este interesat de ale cui etichete.

O tragere one-shot este un semn că un istoric de comitere depășește acum granița dintre unul
cerc de oameni (de exemplu, „oameni care sunt interesați în primul rând de partea de rețea a
kernel") care pot avea propriul set de etichete (de exemplu, „aceasta este a treia versiune candidată
din grupul de rețea care urmează să fie propus pentru consum general cu lansarea 2.6.21") la
un alt cerc de oameni (ex. „oameni care integrează diverse îmbunătățiri ale subsistemului”). The
cei din urmă nu sunt de obicei interesați de etichetele detaliate utilizate intern în primul grup
(asta înseamnă „intern”). De aceea este de dorit să nu urmați etichetele
automat în acest caz.

Este posibil ca printre oamenii care lucrează în rețea să dorească să schimbe etichetele interne
grupului lor, dar în acel flux de lucru ei urmăresc cel mai probabil progresul reciproc
prin a avea filiale de urmărire la distanță. Din nou, euristica pentru a urma automat astfel de etichete
este un lucru bun.

On Backdating Tag-uri
Dacă ați importat unele modificări dintr-un alt VCS și doriți să adăugați etichete pentru major
versiuni ale lucrării dvs., este util să puteți specifica data de încorporat în interiorul fișierului
obiect etichetă; astfel de date din obiectul etichetă afectează, de exemplu, ordonarea etichetelor în
interfata gitweb.

Pentru a seta data utilizată în viitoarele obiecte de etichetă, setați variabila de mediu
GIT_COMMITTER_DATE (vezi discuția ulterioară a valorilor posibile; cea mai comună formă este
„AAAA-LL-ZZ HH:MM”).

De exemplu:

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

DATA FORMATE

Variabilele de mediu GIT_AUTHOR_DATE, GIT_COMMITTER_DATE acceptă următoarea dată
formate:

Format intern Git
Este , Unde este numărul de
secunde de la epoca UNIX. este o compensare pozitivă sau negativă
din UTC. De exemplu, CET (care este cu 2 ore înainte de UTC) este +0200.

RFC 2822
Formatul standard de e-mail, așa cum este descris de RFC 2822, de exemplu joi, 07 aprilie 2005
22:13:13 +0200.

ISO 8601
Ora și data specificate de standardul ISO 8601, de exemplu 2005-04-07T22:13:13. The
analizatorul acceptă și un spațiu în loc de caracterul T.

notițe
În plus, partea dată este acceptată în următoarele formate: AAAA.LL.ZZ,
LL/ZZ/AAAA și ZZ.LL.AAAA.

Utilizați git-tag online folosind serviciile onworks.net