Hur fungerar taggar och releases i Git?

Question

Accepted Answer

**Taggar** markerar specifika punkter i historiken som viktiga — typiskt **releases** (versioner som v1.0.0). Till skillnad från grenar är taggar fasta pekare som inte rör sig, och används för att märka och referera till releaseversioner. De är centrala för versionering och releasehantering.

## Skapa taggar

```bash
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m "Release version 1.0.0"

# lightweight tag (just a pointer, no metadata)
git tag v1.0.0

# tag a specific past commit
git tag -a v1.0.0 <commit> -m "..."
```

**Annoterade taggar** (rekommenderas för releases) lagrar metadata (taggare, datum, meddelande); **lättviktiga taggar** är bara ett namn som pekar på en commit.

## Arbeta med taggar

```bash
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
```

Viktigt: **taggar skjuts inte automatiskt** med `git push` — du måste skjuta dem explicit.

## Taggar vs grenar

```text
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.
```

## Semantisk versionering och releases

```text
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.
```

## Varför det spelar roll

Att förstå taggar och releases är värdefullt för **versionering och releasehantering**, så det är användbar praktisk kunskap för arbete med släppt programvara. **Taggar** markerar viktiga punkter i historiken — typiskt **releaseversioner** (som v1.0.0) — och tillhandahåller fasta, permanenta referenser till specifika commits, vilket är väsentligt för att spåra och referera till vilken kod som utgör varje release.

Att förstå skillnaden mellan **annoterade taggar** (rekommenderas för releases, lagrar metadata som taggare, datum och meddelande) och lättviktiga taggar är praktisk kunskap för korrekt releasetaggning.

Att veta hur man skapar, listar och checkar ut taggar, och viktigt att **taggar inte skjuts automatiskt** (kräver explicit `git push origin --tags` eller att man skjuter specifika taggar — en vanlig fallgrop där människor skapar taggar men glömmer att skjuta dem), är nödvändigt för att korrekt hantera releasetaggar.

Att förstå **taggar vs grenar** (en tagg är en fast pekare till en specifik commit — en permanent etikett som inte rör sig — medan en gren är en rörlig pekare som avancerar med utveckling) förtydligar deras olika roller: taggar för att permanent markera releases/milestones, grenar för pågående arbete.

Att förstå kopplingen till **semantisk versionering** (MAJOR.MINOR.PATCH-konventioner för att kommunicera arten av ändringar) och hur plattformar bygger **Releases** från taggar (med versionanteckningar och artefakter för distribution) återspeglar hur taggar passar in i verklig releasehantering.

Eftersom att släppa och versionera programvara är ett vanligt behov och taggar är Gits mekanism för att markera och referera till releaseversioner (centralt för releasehantering och integrerat med plattformars releasefunktioner), är det värdefullt, praktiskt relevant Git-kunskap att förstå taggar och releases — annoterade vs lättviktiga taggar, att skjuta dem, taggar vs grenar, och deras roll i versionering/releases — för att hantera släppt programvara, en användbar aspekt av professionell utveckling kopplad till versioneringskonventioner och releaseprocesser.