Tags markerer spesifikke punkter i historien som viktige — typisk releases (versjoner som v1.0.0). I motsetning til branches er tags faste pekere som ikke beveger seg, brukt til å merke og referere til releaseversioner. De er sentrale for versjonering og release management.
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m
git tag v1.0.0
git tag -a v1.0.0 <commit> -m
Annotated tags (anbefales for releases) lagrer metadata (tagger, dato, melding); lightweight tags er bare et navn som peker til en commit.
git tag # list tags
git show v1.0.0 # show a tag and its commit
git checkout v1.0.0 # check out the code at a tag (detached HEAD)
# tags are NOT pushed by default — push them explicitly:
git push origin v1.0.0 # push a specific tag
git push origin --tags # push all tags
Viktig: tags pushes ikke automatisk med git push — du pushes dem eksplisitt.
BRANCH → a MOVABLE pointer that advances as you commit (ongoing development)
TAG → a FIXED pointer to a specific commit (a permanent label — doesn't move)
→ Use tags to permanently mark releases/milestones; branches for ongoing work.
SEMANTIC VERSIONING (SemVer): MAJOR.MINOR.PATCH (e.g. v2.3.1)
MAJOR → breaking changes | MINOR → new features (compatible) | PATCH → bug fixes
→ Tags label these versions. Platforms (GitHub) build "Releases" from tags
(with release notes, built artifacts) for distribution.
Å forstå tags og releases er verdifullt for versjonering og release management, så det er nyttig praktisk kunnskap for å arbeide med utgitt programvare. Tags markerer viktige punkter i historien — typisk releaseversioner (som v1.0.0) — og gir faste, permanente referanser til spesifikke commits, noe som er essensielt for sporing og referanse til hvilken kode som utgjør hver release.
Å forstå skillet mellom annotated tags (anbefales for releases, lagrer metadata som tagger, dato og melding) og lightweight tags er praktisk kunnskap for riktig release tagging.
Å vite hvordan du oppretter, lister opp og sjekker ut tags, og viktig at tags ikke pushes automatisk (krever eksplisitt git push origin --tags eller pushing av spesifikke tags — en vanlig feil hvor mennesker oppretter tags men glemmer å pushe dem), er nødvendig for riktig håndtering av release tags.
Å forstå tags vs branches (en tag er en fast peker til en spesifikk commit — en permanent etikett som ikke beveger seg — mens en branch er en flyttbar peker som avanserer med utvikling) klargjør deres ulike roller: tags for permanent merking av releases/milepæler, branches for løpende arbeid.
Å forstå forbindelsen til semantic versioning (MAJOR.MINOR.PATCH-konvensjoner for å kommunisere arten av endringer) og hvordan plattformer bygger Releases fra tags (med release notes og artefakter for distribusjon) gjenspeiler hvordan tags passer inn i faktisk release management.
Siden utgivelse og versjonering av programvare er et vanlig behov og tags er Git-mekanismen for å merke og referere releaseversioner (sentral for release management og integrert med plattformers releasefunksjoner), er forståelse av tags og releases — annotated vs lightweight tags, pushing dem, tags vs branches, og deres rolle i versjonering/releases — verdifull, praktisk relevant Git-kunnskap for håndtering av utgitt programvare, et nyttig aspekt av profesjonell utvikling knyttet til versjonskonvensjoner og release-prosesser.