Hur fungerar Git internt?

Question

Accepted Answer

Internt är Git ett **innehållsadresserbart objektlager** — det lagrar allt som **objekt** (blobbar, träd, commits, taggar) identifierade med deras **SHA-1-hash**. Att förstå denna modell demystifierar Git och förklarar varför dess operationer beter sig som de gör.

## Git är ett innehållsadresserbart objektlager

```text
Git stores 4 types of OBJECTS, each identified by the SHA-1 HASH of its content:
  BLOB   → file CONTENTS (just the data, no filename)
  TREE   → a directory: maps names → blobs (files) and trees (subdirs) + permissions
  COMMIT → a snapshot: points to a TREE (the root) + parent commit(s) + author/message
  TAG    → an annotated tag object (points to a commit, with metadata)
→ Content-addressable: an object's ID IS the hash of its content (same content = same hash).
```

## En commit är en ögonblicksbild, inte en diff

```text
→ Each COMMIT points to a complete TREE (the full state of the project at that point)
→ Git stores SNAPSHOTS, not diffs (though it compresses/deduplicates internally):
  unchanged files → the commit's tree just REUSES the same blob (same hash) → efficient
→ Diffs you see are COMPUTED between snapshots, not stored.
```

## Hur det passar ihop

```text
Branch (e.g. main) → a pointer (a ref) to a COMMIT
HEAD → points to the current branch (or commit)
Commit → tree → blobs (the snapshot)
Commit → parent → parent → ... (the history chain)
→ Branches/tags are just small files containing a commit hash (cheap pointers).
  That's WHY branching is so lightweight.
```

## Varför detta förklarar Gits beteende

```text
✓ Branches are cheap → they're just a 40-char hash in a file (not file copies)
✓ Integrity → content-addressing means corruption/changes are detectable (hash mismatch)
✓ Commits are immutable → changing anything = a new hash = a new commit (why rebase
  creates NEW commits, why history rewriting changes hashes)
✓ Deduplication → identical content stored once (shared blobs)
```

## Varför det är viktigt

Att förstå hur Git fungerar internt är värdefull kunskap på seniornivå eftersom det **demystifierar Git** och förklarar *varför* dess operationer beter sig som de gör, vilket fördjupar din förmåga att resonera om och använda Git med självförtroende.

Kärnmodellen — Git som ett **innehållsadresserbart objektlager** med fyra objekttyper (blobbar för filinnehål, träd för kataloger, commits för ögonblicksbilder, taggar) var och en identifierad av **hashen av dess innehål** — är grunden som allt annat vilar på.

Att förstå att **en commit är en ögonblicksbild, inte en diff** (varje commit pekar på ett komplett träd som representerar projektets fullständiga tillstånd, där oförändrade filer effektivt återanvänder samma blobbar, och diffs beräknas snarare än lagras) korrigerar en vanlig missuppfattning och förklarar Gits ögonblicksbildbaserade modell.

Att se **hur det passar ihop** (grenar och taggar som billiga pekar/refs till commits, HEAD som pekar på den aktuella grenen, commits kedjade via föräldrar) avslöjar den eleganta enkelhet som ligger under ytan.

Mest värdefullt förklarar denna förståelse **Gits observerbara beteende**: varför **grenar är lättviktiga** (bara en hash i en liten fil, inte filkopior — vilket förklarar varför grening är så snabbt), varför Git har **integritet** (innehållsadressering detekterar korruption via hashmatchningar), varför **commits är oföränderliga** och historieomskrivningsoperationer som rebase skapar **nya commits med nya hasher** (att ändra något innehål ändrar hashen), och varför Git **deduplicerar** (identiskt innehål lagras en gång).

Denna djupare modell transformerar Git från en uppsättning memorerade kommandon till ett förståeligt system, vilket möjliggör säker resonering om komplexa operationer.

Since förståelse av den interna objektmodellen förklarar varför Git beter sig som det gör (lättviktiga grenar, oföränderliga commits, hashändringar vid omskrivning, integritet) och lyfter en från att använda Git till att verkligen förstå det, är förståelse av Gits interna struktur värdefull kunskap på seniornivå — ett ämne som återspeglar det djup som förväntas för seniorroller och tillhandahåller den mentala modellen för att resonera om Git med säkerhet, demystifiering av dess beteende och göra avancerade operationer begripliga snarare än mystiska.