Phenquestions
Wat zijn Git-tags?
Git-tags zijn verwijzingen naar bepaalde commits. Ze zijn als bladwijzers. U kunt elke soort conventie gebruiken die u wilt om tags te maken. Maar de meeste ontwikkelteams gebruiken versienummers zoals v1.0.1 of v.1.1-a1 om tags te maken.
Tags maken
Er zijn twee soorten tags in Git:
- Lichtgewicht Tags
- Geannoteerde tags
Lichtgewicht Tags
De lichtgewicht tags zijn eenvoudig te maken. U kunt eenvoudig de volgende opdrachtregel gebruiken:
$git-tagDeze tags worden opgeslagen in de .git-map van je werkrepository.
Laten we een paar lichtgewicht Git-tags maken:
$git-tag v1.0.1$git-tag Release-20190401
In het eerste geval hebben we een tag gemaakt met "v1".0.1”. In het tweede geval hebben we een tag gemaakt met "Release-20190401". De lichtgewicht tags retourneren geen waarde. Het is ook belangrijk om erop te wijzen dat, omdat deze twee tags rug aan rug zijn gedaan, ze naar dezelfde commit verwijzen.
Geannoteerde tags
Met geannoteerde tags kunt u meer informatie opslaan. U kunt de optie "-a" gebruiken om deze tags te maken:
$git-tag -aLaten we proberen een geannoteerde tag te maken:
git tag -a v1.0.2Er verschijnt een tekstvenster waarin u een opmerking kunt invoeren die er als volgt uit moet zien:
## Schrijf een bericht voor tag:
# v1.0.2
# Regels die beginnen met '#' worden genegeerd.
Voer een opmerking in en sla deze op. Dus nu je tag v1.0.2 is opgeslagen met een opmerking. Als alternatief kunt u de opmerking als volgt rechtstreeks in de opdrachtregel invoeren:
git tag -a v1.0.3 -m "Mijn versie 1.0.3"Tags in uw code vinden
Nu we een paar tags hebben gemaakt, laten we eens kijken wat we hebben:
$git-tag -lRelease-20190401
v1.0.1
v1.0.2
v1.0.3
We kunnen zien dat al onze tags in alfabetische volgorde worden weergegeven. U kunt meer informatie over de tags krijgen door de "-n ."
Release-20190401 Bijgewerkt README.md
v1.0.1 Bijgewerkt README.md
v1.0.2 Mijn versie 1.0.2
v1.0.3 Mijn versie 1.0.3
Hier zie je het verschil tussen lichtgewicht en geannoteerde tags. In dit voorbeeld "Release-20190401" en "v1.0.1” zijn lichtgewicht tags. De "v1".0.2” en “v1.0.3” zijn geannoteerde tags. Ze verwijzen allemaal naar dezelfde commit (commit 34671):
$git logcommit 106e0bb02a58ec3e818e9acdf3bb19a9247a0e84 (HEAD -> master, tag: v1.0.4)
Auteur: Zak H
Datum: za 6 apr 21:06:02 2019 -0700
Toegevoegde functie 2
commit 161c6e564e79624623ed767397a98105426d0ec4
Auteur: Zak H
Datum: za 6 apr 21:05:25 2019 -0700
Toegevoegde functie 1
commit 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2,
tag: v1.0.1, label: release-2090401)
Auteur: Zak H
Datum: za 6 april 20:24:53 2019 -0700
Bijgewerkt README.md
commit afe9b0c7c9fbce3c3d585afe67358a5eec226e2c (oorsprong/master)
Auteur: Zak H
Datum: za 6 apr 20:23:55 2019 -0700
In het
De lichtgewicht tags tonen echter de opmerkingen van de commit zelf die "Updated README" is.md”, terwijl de geannoteerde tags de individuele opmerkingen tonen die eraan zijn toegevoegd tijdens het maken van de tag.
Tip: Als je het commit-nummer van een bepaalde tag wilt vinden, kun je de opdracht "git show" gebruiken:
$git show v1.0.3tag v1.0.3
Tagger: Zak H
Datum: za 6 apr 20:43:30 2019 -0700
Mijn versie 1.0.3
commit 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2, label:
v1.0.1, label: release-2090401)
Auteur: Zak H
Datum: za 6 apr 20:24:53 2019 -0700
Bijgewerkt README.md
diff --git a/README.md b/LEESMIJ.md
index 9daeafb… 180cf83 100644
--- a/LEESMIJ.md
+++ b/LEESMIJ.md
@@ -1 +1 @@
-test
+test2
Oudere toezeggingen taggen
Je kunt ook teruggaan en een oudere commit taggen. Laten we eens kijken naar de logboeken:
$git log --oneline106e0bb (HEAD -> meester, tag: v1.0.4) Toegevoegde functie 2
161c6e5 Functie toegevoegd 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1, tag: Release-20190401) Bijgewerkt README.md
afe9b0c (oorsprong/master) Init
$
We merken dat de commit 161c6e5 geen bijbehorende tag heeft. We kunnen deze commit als volgt taggen:
$git tag -a Release-20190402 161c6e5Het zal het commentaarvenster openen. Nadat we de opmerking hebben geplaatst, kunnen we zien dat de commit nu is getagd:
$git-tag -n1Release-20190401 Bijgewerkt README.md
Release-20190402 Tag toegevoegd aan een oudere commit
v1.0.1 Bijgewerkt README.md
v1.0.2 Mijn versie 1.0.2
v1.0.3 Mijn versie 1.0.3
v1.0.4 Functie toegevoegd 2
Tags verwijderen
Stel dat u besluit dat u de "Release-"-tags niet wilt, omdat ze verwarrend zijn. Je kunt eerst alle “Release-“ tags vinden:
$git-tag -l Vrijgeven*Release-20190401
Release-20190402
Nu kunt u ze verwijderen met de "-d" optie:
$git tag -d Release-20190401Tag 'Release-20190401' verwijderd (was 34671d8)
$git tag -d Release-20190402
Tag 'Release-20190402' verwijderd (was 6ee37bc)
Als we de tags opnieuw controleren, zouden we alleen de tags moeten zien die beginnen met "v":
$git-tag -n1v1.0.1 Bijgewerkt README.md
v1.0.2 Mijn versie 1.0.2
v1.0.3 Mijn versie 1.0.3
v1.0.4 Functie toegevoegd 2
Tags overschrijven
Stel dat we een situatie hebben waarin "v1".0.4” tag is gericht op Feature 2:
$git log --onelined7b18a4 (HEAD -> master) Functie toegevoegd 3
106e0bb (tag: v1.0.4) Toegevoegde functie 2
161c6e5 Functie toegevoegd 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Bijgewerkt README.md
afe9b0c (oorsprong/master) Init
Maar we willen de tag “v1.0.4” wijst naar kenmerk 3. Als we het opnieuw proberen te taggen, krijgen we deze foutmelding:
$git-tag v1.0.4 d7b18a4fataal: tag 'v1'.0.4' bestaat al
We kunnen dit probleem oplossen met de optie "-f":
$git-tag -f v1.0.4 d7b18a4Bijgewerkte tag 'v1'.0.4' (was 106e0bb)
Als we het logboek opnieuw controleren, zien we dat de tag is verplaatst naar de commit die we willen:
$git log --onelined7b18a4 (HEAD -> master, tag: v1.0.4) Toegevoegde functie 3
106e0bb Functie toegevoegd 2
161c6e5 Functie toegevoegd 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) Bijgewerkt README.md
afe9b0c (oorsprong/master) Init
Als alternatief kun je ook een tag verwijderen en opnieuw toevoegen aan een nieuwe commit.
Tags delen met andere gebruikers
Wanneer je je code naar je externe repository pusht, worden Git-tags niet automatisch gepusht. Als je je tags met andere gebruikers wilt delen, moet je ze exclusief pushen.
De tags kunnen als volgt worden gepusht:
$git push origin v1.0.4Objecten tellen: 12, klaar.
Delta-compressie met maximaal 4 threads.
Objecten comprimeren: 100% (4/4), klaar.
Schrijven van objecten: 100% (12/12), 902 bytes | 150.00 KiB/s, klaar.
Totaal 12 (delta 0), hergebruikt 0 (delta 0)
Naar /Gebruikers/zakh/_work/LearnGIT/git_tagging/remote/project_mayhem
* [nieuwe tag] v1.0.4 -> v1.0.4
Als andere gebruikers nu de externe repository klonen, zien ze alleen de tag die is gepusht (“v1.0.4” in dit geval).
Vertakkingen versus tags gebruiken
Branches zijn handig voor nieuwe functies of om te experimenteren. Over het algemeen wil je vertakken wanneer er toekomstig werk moet worden gedaan en het werk je huidige ontwikkeling verstoort. Aan de andere kant zijn tags nuttiger als snapshots. Je moet ze gebruiken om bepaalde dingen te onthouden die je al hebt gedaan.
Tot slot
Git-tag is een onderbenutte functie die een geweldige manier kan zijn om releases en speciale functies bij te houden. Als u goede praktijken opstelt rond tags, kan dit u helpen om gemakkelijk met uw ontwikkelteam te communiceren en uw ontwikkelprocessen te vereenvoudigen.
Verdere studie:
- https://git-scm.com/book/nl/v2/Git-Basics-Tagging
- https://software-engineering.stapeluitwisseling.com/questions/165725/git-branching-and-tagging-best-practices
- https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-tag
- https://nl.wikipedia.org/wiki/Software_versioning
- https://www.techopedia.com/definition/25977/softwareversiebeheer
