Commits

En commit er mere end en kommando — det er jeres historie, jeres samarbejde og jeres sikkerhedsnet. Her får du både den bløde vinkel og den tekniske proces.

Hvorfor er commits vigtige?

Hver gang I gemmer et snapshot af jeres kode, skriver I et kapitel i projektets historie. Gode commits gør teamwork nemmere og fejl mindre skræmmende.

  • Et snapshot af dit arbejde — En commit gemmer præcis hvordan koden så ud på et givent tidspunkt — som et foto I kan vende tilbage til.
  • Historie og sporbarhed — Med gode commit-beskeder kan I (og jeres kunde) følge hvad der er ændret, hvornår og hvorfor.
  • Teamarbejde — Commits er byggestenene i samarbejdet. Små, tydelige commits gør det nemt for holdkammerater at forstå og reviewe jeres ændringer.
  • Tryghed ved fejl — Har I lavet noget forkert? Med commits kan I rulle tilbage til en tidligere version uden panik.

Sådan committer vi

Nogle vaner gør jeres Git-historik læsbar for holdkammerater, undervisere og kunder.

  • Commit ofte

    Lav små commits med én logisk ændring ad gangen — ikke én kæmpe commit fredag eftermiddag med hele sprinten.

  • Skriv til mennesker

    Commit-beskeden skal forklare hvad og hvorfor — ikke bare "fix" eller "update". Forestil dig at en holdkammerat læser den om 3 måneder.

  • Brug conventional commits

    Formatet type(scope): beskrivelse gør historikken læsbar og kobler direkte til semver og release-noter.

  • Commit aldrig direkte på main

    Arbejd på en feature branch og merge via pull request. Main er jeres leverance-klare kode.

Conventional Commits

Formatet type(scope): beskrivelse er standard i professionelle teams og open source. Det kobler direkte til release-noter og semver — præcis som I så i Dokploy-eksemplet med fix(backups) og chore(dependencies).

Byg din egen conventional commit og se formatet live

$git commit -m "feat(auth): tilføj login-side med JWT"

Ny funktionalitet — noget brugeren kan se eller bruge.

Typisk semver: MINOR

Eksempel: feat(auth): tilføj login med JWT

Git's zoner — visuelt

Fra redigeret fil til commit på GitHub — klik gennem zonerne og se hvor data befinder sig.

Klik på trinene og se hvordan ændringer bevæger sig gennem Git's zoner

working dirstagingrepositoryGitHub

Du redigerer filer

Ændringer i din editor lander i working directory. Git kan se dem (git status), men de er endnu ikke staged eller committed.

Dårlige vs. gode beskeder

Beskeden er til mennesker — ikke bare til Git. Sammenlign:

Undgå
fix
Gør i stedet
fix(nav): luk mobilmenu ved klik udenfor

Forklar hvad der blev rettet og hvor.

Undgå
update og ting
Gør i stedet
feat(dashboard): tilføj projektoversigt

Brug type og scope — "update" siger intet.

Undgå
WIP
Gør i stedet
refactor(api): udtræk fetch-logik til service

WIP-commits hører ikke til i delt historik — commit når ændringen er færdig.

Undgå
fixed bug reported by teacher
Gør i stedet
fix(auth): redirect til login ved udløbet session

Beskriv problemet løst, ikke hvem der rapporterede det.


Fra ændring til push

Git har tre "zoner": working directory, staging area og repository. Klik på hvert trin for at se hvad der sker.

Klik på hvert trin for at se forklaring og kommandoer

Du arbejder lokalt

Når du redigerer filer i dit projekt, er ændringerne først kun i din working directory. Git tracker dem, men de er endnu ikke en del af historikken.

Trin-for-trin guide

Sådan laver du din første rigtige commit — fra status til push.

0 / 5 fuldført

Før du committer, bør du altid vide præcis hvad du putter i historikken. git status viser ændrede, staged og untracked filer. git diff viser de konkrete linje-ændringer.

Terminal
git status

# Se ændringer i filer:
git diff

# Se hvad der er staged:
git diff --staged

Test din viden

Svar på spørgsmålene for at tjekke om du har styr på commits og conventional commits.

Hvad gør git add?

Hvilken commit-type bruger du til en ny side i appen?

Hvad er forskellen på git commit og git push?

Hvilken semver-bump hører typisk til en fix-commit?

Hvorfor bør du undgå at committe direkte på main?