Hvordan du overlever Git uden at kende hele værktøjet

Git er kedeligt komplekst, men du behøver kun en lille del

Git føles ofte som et kæmpe værktøj til et ret simpelt behov: du vil bare gemme dit arbejde, kunne fortryde ting og dele kode med andre.

Min påstand: som begynder har du brug for under 15 kommandoer. Resten er støj, indtil du rammer en konkret mur.

For at gøre det overskueligt bruger jeg én gennemgående sammenligning i artiklen:

Hele denne artikel handler faktisk om at gå fra venstre kolonne til højre kolonne på den mindst smertefulde måde.

Hvad du har brug for (og hvad du roligt kan ignorere i starten)

Det her er en minimal version af git for begyndere. Du kan bygge alt skole- og hobbykode på det her:

De få kommandoer du skal kunne

• git status – se hvad der ændret sig
• git add . – markér ændringer til næste commit
• git commit -m "besked" – gem et trin i historikken
• git branch / git branch navn – se eller lave branch
• git switch navn – skift branch (ny kommando, bedre end checkout)
• git push – skub dine commits op
• git pull – hent andres ændringer ned
• git log --oneline – se historikken kort

Alt andet er nice to have, indtil du faktisk mangler det.

Hvad du kan ignorere i starten

• Rebase-flows med 10 steps
• Submodules
• Hooks og avanceret config
• Intern filstruktur i .git
• Signing af commits og GPG-nøgler

Hvis du en dag vil lege mere nørdet med Git, kan du altid komme tilbage. Lige nu gælder det om at få en rytme der virker hver dag.

Grundsetup: repo, clone og status

Du møder typisk Git på to måder:

1. Du har en mappe lokalt og vil gøre den til et Git-repo.
2. Du bliver inviteret til et repo på GitHub/GitLab og skal hente det ned.

Fra almindelig mappe til Git-repo

Du har fx en mappe mit-projekt med noget HTML, CSS og Python.

cd mit-projekt

# gør mappen til et git-repo
git init

# tjek status
git status

git status er din “hvordan ser verden ud lige nu?” kommando. Brug den konstant. Seriøst.

Clone: når repoet starter på GitHub

Hvis repoet allerede lever på GitHub, skal du clone det.

git clone https://github.com/brugernavn/projekt.git
cd projekt

git status

Clone svarer til at lave første kopi af projektet ned på din maskine.

Status: din bedste ven

git status fortæller dig:

• Hvilken branch du står på
• Hvilke filer er ændret
• Om der er noget klar til commit

Brug den:

git status
# "On branch main"
# "Changes not staged for commit"

Hvis du føler dig forvirret i Git, så er første step altid: kør git status.

Den daglige rytme: edit → add → commit

Når du koder alene uden Git, er din rytme:

• Rediger filer
• Gem i editoren

Med Git får du en ekstra rytme ovenpå:

• Rediger filer
• Gem i editoren
• git add
• git commit

Trin 1: lav en ændring

Du ændrer fx i index.html og style.css. Så kører du:

git status

Du vil nu se de to filer som ændrede.

Trin 2: git add

git add fortæller Git: “de her ændringer vil jeg gerne have med i næste snapshot”.

Hvis du vil tage alle ændringer:

git add .

Hvis du kun vil tage én fil:

git add index.html

Trin 3: git commit med gode beskeder

Nu vil du gemme et logisk trin i historien. Tænk på det som et checkpoint i et spil.

git commit -m "Tilføj hero-sektion på forsiden"

Gode commit-beskeder handler om hvad og helst lidt hvorfor. Dårlige beskeder er:

• fix
• update
• asdasdasd (ja, jeg har også gjort det)

Gode beskeder kan være:

• Ret bug i login-validering for tomt password
• Refaktor navbar til at bruge flexbox
• Tilføj simpel README med kørselsinstruktion

Hvis du vil dykke mere ned i commit-struktur senere, kan du fx læse en artikel om god kodekvalitet og struktur på Coding Class, men lige nu er reglen: skriv noget, din fremtidige hjerne forstår.

Mini-øvelse: byg din første historie

1. Lav en ny mappe git-test
2. Lav en fil notes.txt med en linje tekst
3. Kør git init
4. Kør git add . og git commit -m "Første note"
5. Rediger filen, tilføj en ny linje
6. Commit igen med en ny besked
7. Kør git log --oneline og se din lille historik

Branch workflow: fra “kopimappe” til feature branch

Uden Git laver man varianter af projektet som:

• projekt_ny_login
• projekt_med_nyt_design

Med Git bruger du branches til det samme.

Se og lave branches

# se nuværende branch
git branch

# lav ny branch
git branch feature-login

# skift til den nye branch
git switch feature-login

Nu står du på en gren af projektet, hvor du kan eksperimentere. Din main branch er stadig ren.

Hvorfor ikke bare arbejde direkte på main?

Sammenligning:

Som tommelfingerregel: ny opgave = ny branch.

Minimal branch workflow

1. Start på main: git switch main
2. Hent seneste: git pull
3. Lav branch: git branch feature-login
4. Skift: git switch feature-login
5. Kod, commit, gentag
6. Push branchen op: git push --set-upstream origin feature-login

Push og pull: sådan undgår du de værste konflikter

Her går mange begyndere i stå. Ikke fordi kommandoerne er svære, men fordi timingen er forkert.

Sådan tænker du på push og pull

• Push: send mine commits op til serveren (GitHub).
• Pull: hent andres commits ned til mig.

Hvis flere arbejder på samme branch, vil I let træde hinanden over tæerne. Derfor:

• Pull før du starter dagens arbejde.
• Pull før du laver en vigtig merge.
• Push i mindre bidder, ikke én kæmpe portion efter en uge.

Standardcyklus med remote

# start dagen
git switch feature-login
git pull

# arbejd, commit lokalt
git add .
git commit -m "Tilføj basic login-form"

# skub op
git push

Hvis Git beder dig om git pull --rebase eller lignende, og du ikke helt ved hvad du laver: stop, tag en kollega eller følg reglen lidt længere nede i afsnittet om merge vs rebase.

Pull request: hvad kigger en reviewer efter?

En pull request (PR) er bare: “Hej, jeg har lavet noget på den her branch, vil I merge det ind på main?”

Flowet er typisk:

1. Lav branch
2. Kod, commit, push
3. Åbn PR på GitHub/GitLab
4. Få review
5. Merge når alle er tilfredse

Minimal PR-checkliste til begyndere

Inden du trykker “Create pull request”, så tjek:

• Står du på den rigtige branch? (ikke direkte på main)
• Er main opdateret? (har du kørt git pull på main før du brancher?)
• Beskrivelse: hvad har du lavet, og er der noget der mangler?
• Bygget/kørt lokalt: fejler testen ikke bare lige foran reviewers?
• Filer: har du undgået at committe .env, store build-mapper osv.?

Hvis du vil øve PR’s alene, kan du lave et lille projekt, pushe til GitHub og lave PR fra en feature-branch ind i main, selv om det kun er dig i repoet. Det er god træning.

Merge vs rebase: en simpel beslutningsregel

Git diskussioner kan hurtigt blive religiøse, især omkring merge vs rebase. Til git for begyndere behøver du én simpel regel:

Beslutningsregel

• Brug merge når du arbejder sammen med andre på samme repo.
• Brug rebase kun på dine egne lokale branches, og kun når du forstår hvad der sker.

Hvad er forskellen i praksis?

Eksempel: hold din branch opdateret med main (merge-version)

# stå på main
git switch main
git pull

# tilbage til din feature-branch
git switch feature-login

# merge main ind i din branch
git merge main

Hvis der er konflikter, tager du dem nu, inden du åbner PR. Det får dine reviewers til at holde mere af dig.

Vil du nørde forskellen mere, kan du senere finde en artikel om workflow og Git på Coding Class, men til at starte med er merge rigeligt.

Fejlretning: 6 klassiske Git-problemer og sikre løsninger

Git bliver først skræmmende, når man er bange for at miste arbejde. Så vi tager fejlene på en måde, hvor du maksimerer sikkerhed.

0. Først: lav en sikkerhedskopi når du er nervøs

Hvis du er i panik, så gør det her inden du forsøger at fixe noget:

# i projektets rodmappe
cp -r . ../projekt-backup-$(date +%s)

Så har du en kopi af hele mappen liggende ved siden af. Ikke smukt, men det virker.

1. “Jeg er i detached HEAD”

Du har måske kørt git checkout <commit-id> og pludselig står der:

HEAD is detached at <hash>

Oversat: du står ikke længere på en navngiven branch, men på et bestemt commit.

Hvis du har lavet arbejde her og vil gemme det sikkert:

# lav en ny branch ud fra hvor du står
git branch red-mig-ud-af-det-her

git switch red-mig-ud-af-det-her

Nu er dit arbejde på en rigtig branch. Herfra kan du merge den ind i fx main senere.

2. “Jeg har committed til den forkerte branch”

Du troede du stod på feature-login, men du stod på main. Klassisk.

Hvis du ikke har pushet endnu:

# lav ny branch fra nuværende tilstand
git branch feature-login

# skift til main før fejlen
git switch main

# flyt main tilbage én commit
git reset --hard HEAD~1

# skift til din nye branch
git switch feature-login

Nu ligger committen på feature-login i stedet for main.

Hvis du allerede har pushet til remote, så lad være med at bruge reset --hard uden at tale med resten af holdet. I det tilfælde er en mere sikker løsning at lave en “revert” commit, eller at leve med at den commit ligger på main.

3. “Jeg vil fortryde ændringer i en fil før commit”

Du har rodet i en fil, men vil tilbage til seneste commit:

# fortryd ændringer i én fil
git restore filnavn

# fortryd alle ikke-commit-tede ændringer
git restore .

Vigtigt: det her smider ændringerne væk. Hvis du er i tvivl, så kopier filen et andet sted hen først.

4. “Jeg har staged noget, jeg ikke vil have med i commit”

Du har kørt git add ., men fortrudt at en fil skal med:

# fjern én fil fra staging
git restore --staged filnavn

# fjern alt fra staging
git restore --staged .

Det ændrer ikke filerne, kun hvad der er klar til commit.

5. “Jeg har conflicts efter merge/pull”

Du ser noget i stil med:

CONFLICT (content): Merge conflict in filnavn

Og i filen ser du:

<<<<<<< HEAD
lokal version
=======
remote version
>>>>>>> main

Løsning:

1. Åbn filen i editoren
2. Vælg hvad der skal være tilbage (lokal, remote eller en blanding)
3. Slet konflikt-markørerne <<<<<<<, =======, >>>>>>>
4. Gem filen
5. Stage og commit

git add filnavn
git commit -m "Løs merge-konflikt i filnavn"

Hvis det går helt galt, så husk backup-tricket fra tidligere. Du kan altid kopiere den gode version ud af backup-mappen og ind igen.

6. “Jeg vil se hvad jeg har ændret siden sidst”

Her er det nyttigt at kunne sammenligne:

# se ændringer siden sidste commit
git diff

# se ændringer i en specifik fil
git diff filnavn

Det er lidt som at have "track changes" for kode. Godt når du vil være sikker på, hvad du faktisk er ved at committe.

Sådan kan du bygge videre på dit Git-setup

Når den her minimale workflow sidder nogenlunde i hænderne, kan du langsomt bygge på:

• Brug Git direkte i din editor (VS Code har indbygget Git UI)
• Opsæt .gitignore så du ikke committer unødvendige filer
• Tilføj simple CI-checks på GitHub til at køre tests på hver PR
• Lær git stash, når du vil gemme halvfærdigt arbejde midlertidigt

Hvis du vil videre fra begynder til mere rutineret, kan du fx kombinere det her med en artikel om versionsstyring eller workflow på Coding Class, eller bruge et lille hobbyprojekt som legeplads, hvor det er helt ok at lave rod undervejs.