Hvordan du bruker git -tagger for å forbedre utviklingsprosessene dine

For de fleste utviklingsteam har Git blitt et viktig verktøy for versjonskontroll. En stor grunn til Gits popularitet er dens sømløse evne til å lage grener. Utviklingsteam kan bruke filialer til å jobbe med spesifikke funksjoner eller utgivelser. Imidlertid er Gits tagge en ofte oversett kommando som kan hjelpe team. I denne artikkelen vil vi dykke inn i hva som er, hvordan er og hvorfor er git -tagging.

Hva er git -tagger?

Git -tagger er pekere på visse forpliktelser. De er som bokmerker. Du kan bruke alle slags stevner du vil lage tagger. Men de fleste utviklingsteam bruker versjonsnumre som V1.0.1 eller v.1.1-A1 for å lage tagger.

Opprette tagger

Det er to typer tagger i git:

• Lette tagger
• Kommenterte tagger

Lette tagger

De lette taggene er enkle å lage. Du kan ganske enkelt bruke følgende kommandolinje:

$ git tag

Disse taggene er lagret i .Git -mappen til arbeidsreposten din.

La oss lage noen få lette git -tagger:

$ git tag v1.0.1
$ git tag utgivelse-20190401

I det første tilfellet opprettet vi en tag med “V1.0.1". I det andre tilfellet opprettet vi en tag med "Release-20190401". De lette taggene returnerer ikke noen verdi. Det er også viktig å påpeke at fordi disse to taggene ble gjort rygg mot rygg, peker de på samme forpliktelse.

Kommenterte tagger

Annoterte tagger lar deg lagre mer informasjon. Du kan bruke alternativet “-a” for å opprette disse taggene:

$ git tag -a

La oss prøve å lage en kommentert tag:

git tag -a v1.0.2

Det vil hylle et tekstvindu for deg å legge inn en kommentar som skal se slik ut:

#
# Skriv en melding for tag:
# v1.0.2
# Linjer som begynner med '#' vil bli ignorert.

Skriv inn en kommentar og lagre den. Så nå taggen V1.0.2 lagres med en kommentar. Alternativt kan du direkte legge inn kommentaren i kommandolinjen som denne:

git tag -a v1.0.3 -m "Min versjon 1.0.3 "

Finne tagger i koden din

Nå som vi har laget noen få tagger, la oss se hva vi har:

$ git tag -l
Utgivelse-20190401
v1.0.1
v1.0.2
v1.0.3

Vi kan se at alle kodene våre vises i alfabetisk rekkefølge. Du kan få mer informasjon om taggene ved å bruke "-n" der står for antall linjer i kommentarene.

$ git tag -n1
Release-20190401 Oppdatert ReadMe.MD
v1.0.1 Oppdatert Readme.MD
v1.0.2 Min versjon 1.0.2
v1.0.3 Min versjon 1.0.3

Her kan du merke en forskjell mellom lette og kommenterte tagger. I dette eksemplet “Release-20190401” og “V1.0.1 ”er lette tagger. “V1.0.2 ”og“ V1.0.3 ”er kommenterte tagger. Alle peker på samme forpliktelse (forpliktelse 34671):

$ git log
forpliktelse 106e0bb02a58ec3e818e9acdf3bb19a9247a0e84 (head -> master, tag: v1.0.4)
Forfatter: Zak H
Dato: Lør 6. april 21:06:02 2019 -0700
Lagt til funksjon 2
Commit 161c6e564e79624623Ed767397a98105426d0ec4
Forfatter: Zak H
Dato: Lør 6. april 21:05:25 2019 -0700
Lagt til funksjon 1
forpliktelse 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2,
Tag: v1.0.1, tag: utgivelse-20190401)
Forfatter: Zak H
Dato: Lør 6. april 20:24:53 2019 -0700
Oppdatert Readme.MD
Commit Afe9B0C7C9FBCE3C3D585AFE67358A5EEC226E2C (Origin/Master)
Forfatter: Zak H
Dato: Lør 6. april 20:23:55 2019 -0700
I det

Imidlertid viser de lette taggene kommentarene fra selve forpliktelsen som er "oppdatert readme.MD ”, mens de kommenterte taggene viser de individuelle kommentarene som ble lagt til dem under opprettelsesprosessen.

Tips: Hvis du vil finne forpliktelsesnummeret til en bestemt tag, kan du bruke kommandoen “Git Show”:

$ git show v1.0.3
Tag v1.0.3
Tagger: Zak H
Dato: Lør 6. april 20:43:30 2019 -0700
Min versjon 1.0.3
forpliktelse 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2, tag:
v1.0.1, tag: utgivelse-20190401)
Forfatter: Zak H
Dato: Lør 6. april 20:24:53 2019 -0700
Oppdatert Readme.MD
Diff -Git A/Readme.MD B/Readme.MD
Indeks 9Daeafb ... 180CF83 100644
--- a/readme.MD
+++ b/readme.MD
@@ -1 +1 @@
-test
+Test2

Merking av eldre forpliktelser

Du kan også gå tilbake og merke en eldre forpliktelse. La oss se på tømmerstokkene:

$ git log --oneline
106E0BB (Head -> Master, Tag: V1.0.4) Lagt til funksjon 2
161C6E5 lagt til funksjon 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1, tag: utgivelse-20190401) Oppdatert Readme.MD
AFE9B0C (Origin/Master) Init
$

Vi merker at Commit 161c6e5 ikke har en tilknyttet tag. Vi kan merke denne forpliktelsen slik:

$ git tag -A Release -20190402 161C6E5

Det vil hylle kommentarvinduet. Etter at vi har lagt inn kommentaren, kan vi se at vi har forpliktelsen merket nå:

$ git tag -n1
Release-20190401 Oppdatert ReadMe.MD
Utgivelse-20190402 Lagt til en eldre forpliktelse
v1.0.1 Oppdatert Readme.MD
v1.0.2 Min versjon 1.0.2
v1.0.3 Min versjon 1.0.3
v1.0.4 Lagt til funksjon 2

Fjerne tagger

Anta at du bestemmer deg for at du ikke vil ha "utgivelsen-" tags som de er forvirrende. Du kan først finne alle “Release-” -merker:

$ git tag -l utgivelse*
Utgivelse-20190401
Utgivelse-20190402

Nå kan du fjerne dem med "-D" -alternativet:

$ git tag -D Release -20190401
Slettet tag 'utgivelse-20190401' (var 34671d8)
$ git tag -D Release -20190402
Slettet tag 'utgivelse-20190402' (var 6eee37bc)

Hvis vi sjekker taggene igjen, bør vi bare se taggene som starter med “V”:

$ git tag -n1
v1.0.1 Oppdatert Readme.MD
v1.0.2 Min versjon 1.0.2
v1.0.3 Min versjon 1.0.3
v1.0.4 Lagt til funksjon 2

Overskriving av tagger

Anta at vi har en situasjon der “v1.0.4 ”-taggen er å spille 2:

$ git log --oneline
d7b18a4 (head -> master) lagt til funksjon 3
106e0bb (tag: v1.0.4) Lagt til funksjon 2
161C6E5 lagt til funksjon 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Oppdatert readme.MD
AFE9B0C (Origin/Master) Init

Men vi vil ha taggen “V1.0.4 ”å peke på funksjon 3. Hvis vi prøver å ta det tilbake, får vi denne feilen:

$ git tag v1.0.4 D7B18A4
FATAL: TAG 'V1.0.4 'eksisterer allerede

Vi kan overvinne dette problemet med alternativet “-f”:

$ git tag -f v1.0.4 D7B18A4
Oppdatert tag 'v1.0.4 '(var 106e0bb)

Hvis vi sjekker loggen igjen, ser vi at taggen har flyttet til forpliktelsen vi ønsker:

$ git log --oneline
D7B18A4 (Head -> Master, Tag: V1.0.4) Lagt til funksjon 3
106e0bb lagt til funksjon 2
161C6E5 lagt til funksjon 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Oppdatert readme.MD
AFE9B0C (Origin/Master) Init

Alternativt kan du også slette en tag og legge den til på nytt til en ny forpliktelse.

Deling av tagger med andre brukere

Når du skyver koden din til det eksterne depotet, blir ikke git -tagger skyvet automatisk. Hvis du vil dele taggene dine med andre brukere, må du utelukkende skyve dem.

Taggene kan skyves slik:

$ git push origin v1.0.4
Teller objekter: 12, gjort.
Delta -komprimering ved bruk av opptil 4 tråder.
Komprimerende objekter: 100% (4/4), gjort.
Skrive objekter: 100% (12/12), 902 byte | 150.00 kib/s, gjort.
Totalt 12 (Delta 0), gjenbrukt 0 (Delta 0)
Til/brukere/zakh/_work/learngit/git_tagging/ekstern/project_mayhem
* [Ny tag] V1.0.4 -> V1.0.4

Hvis andre brukere kloner det eksterne depotet, vil de bare se taggen som ble presset (“V1.0.4 ”i dette tilfellet).

Bruke grener vs tagger

Grener er nyttige for nye funksjoner eller eksperimentere. Generelt vil du forgrene deg når det er fremtidig arbeid som må gjøres, og arbeidet er forstyrrende for din nåværende utvikling. På den annen side er tagger mer nyttige som øyeblikksbilder. Du bør bruke dem til å huske bestemte ting du allerede har gjort.

For å konkludere

Git-taggen er en underutnyttet funksjon som kan gi en flott måte å holde rede på utgivelser og spesielle funksjoner. Hvis du setter opp god praksis rundt tagger, kan det hjelpe deg med å kommunisere med utviklingsteamet ditt og forenkle utviklingsprosessene dine.

Videre studier:

• https: // git-cm.com/bok/en/v2/git-basics-tagging
• https: // softwareengineering.Stackexchange.COM/SPØRSMÅL/165725/GIT-forgrening og tagging-best-praksis
• https: // www.Atlassian.com/git/tutorials/Inspecting-a-Repository/git-tag
• https: // no.Wikipedia.org/wiki/software_versioning
• https: // www.Techopedia.com/definisjon/25977/programvareversjoning