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
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
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:
fix fix(nav): luk mobilmenu ved klik udenfor Forklar hvad der blev rettet og hvor.
update og ting feat(dashboard): tilføj projektoversigt Brug type og scope — "update" siger intet.
WIP refactor(api): udtræk fetch-logik til service WIP-commits hører ikke til i delt historik — commit når ændringen er færdig.
fixed bug reported by teacher 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.
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?