8.4 Versjonskontroll med Git | IT 1

Lær Git for versjonskontroll: repository, commit, branch, merge og GitHub.

65 min

7 oppgaver

VersjonskontrollGitRepositoryCommit

Du leser den tradisjonelle versjonen

Din fremgang i kapitlet

0 / 7 oppgaver

Versjonskontroll med Git

Har du noen gang lagret filer med navn som prosjekt_v1.html, prosjekt_v2_ENDELIG.html, prosjekt_v3_ENDELIG_NY.html? Eller kanskje du har gjort en endring som ødela noe, og du anga at du ikke hadde en kopi av den forrige versjonen? Versjonskontroll løser disse problemene.

Git er et versjonskontrollsystem som holder styr på alle endringer du gjør i prosjektet ditt. Det er som en tidmaskin for koden din – du kan se hele endringshistorikken, gå tilbake til en hvilken som helst tidligere versjon, og samarbeide med andre uten å overskrive hverandres arbeid.

Git er det mest brukte verktøyet i profesjonell programvareutvikling. Uansett om du jobber alene eller i et team, er Git en ferdighet du trenger. I dette kapittelet lærer du de grunnleggende konseptene og kommandoene du trenger for å komme i gang.

Git

Git er et distribuert versjonskontrollsystem som sporer endringer i filer og koordinerer arbeid mellom flere personer. Git ble utviklet av Linus Torvalds i 2005 for å håndtere utviklingen av Linux-kjernen. Distribuert betyr at hver utvikler har en komplett kopi av hele prosjekthistorikken, slik at du kan jobbe offline og ikke er avhengig av en sentral server. Git er gratis, åpen kildekode, og brukes av alt fra enkeltpersonprosjekter til de største programvareprosjektene i verden.

Hvorfor versjonskontroll er uunnværlig

Versjonskontroll gir deg flere superkrefter:

1. Historikk: Hver endring du gjør lagres med en beskrivelse. Du kan se nøyaktig hva som ble endret, når og av hvem. Dette er uvurderlig når du lurer på hvorfor koden ser ut som den gjør, eller når noe plutselig slutter å fungere.

2. Angre-funksjon: Gjorde du en feil? Du kan gå tilbake til en hvilken som helst tidligere versjon av prosjektet. Ingen endring er permanent – du kan alltid rulle tilbake.

3. Parallell utvikling: Med brancher kan du jobbe på en ny funksjon uten å forstyrre den fungerende koden. Når funksjonen er ferdig, slår du den sammen med hovedkoden.

4. Samarbeid: Flere personer kan jobbe på det samme prosjektet samtidig uten å overskrive hverandres endringer. Git holder styr på hvem som endret hva og hjelper med å slå sammen arbeidet.

5. Eksperimentering: Du kan prøve ut ideer i en egen branch uten risiko. Fungerer det? Slå det sammen. Fungerer det ikke? Slett branchen og ingen skade er gjort.

6. Sikkerhetskopi: Når du dytter (push) koden til GitHub, har du en sikkerhetskopi i skyen. Selv om datamaskinen din dør, er koden trygg.

De viktigste Git-begrepene

Før vi ser på kommandoer, la oss forstå de sentrale begrepene:

Repository (repo)

Et repository er prosjektmappen din med Git aktivert. Det inneholder alle prosjektfilene dine pluss en skjult .git-mappe som lagrer hele endringshistorikken. Du kan ha et lokalt repo på maskinen din og et eksternt (remote) repo på GitHub.

Working Directory, Staging Area og Repository

Git har tre «områder» for filer:

1. Working Directory: Mappen du jobber i. Endringer her er ikke lagret i Git ennå.
2. Staging Area (Index): Et mellomsteg der du velger hvilke endringer som skal inkluderes i neste commit. Du legger filer til staging med git add.
3. Repository: Den permanente historikken. Når du kjører git commit, lagres endringene fra staging area som et nytt punkt i historikken.

Arbeidsmappe  -->  Staging Area  -->  Repository
 (endringer)      (klargjort)       (lagret historikk)
    git add           git commit

Commit

En commit er et øyeblikksbilde av prosjektet ditt på et bestemt tidspunkt. Tenk på det som et lagringspunkt i et spill – du kan alltid gå tilbake hit.

Branch

En branch er en parallell utviklingslinje. Hovedbranchen heter main. Når du vil lage en ny funksjon, lager du en ny branch, gjør endringene der, og merger tilbake til main når du er ferdig.

✏️De viktigste Git-kommandoene

Her er de grunnleggende Git-kommandoene du trenger for å komme i gang:

Oppsett og oppretting:

# Opprett et nytt Git-repository i gjeldende mappe
git init

# Klon et eksisterende repository fra GitHub
git clone https://github.com/brukernavn/prosjekt.git

# Konfigurer navn og e-post (gjøres én gang)
git config --global user.name "Ditt Navn"
git config --global user.email "din@epost.no"

Daglig arbeid:

# Se status – hvilke filer er endret?
git status

# Legg til en fil i staging area
git add filnavn.html

# Legg til alle endrede filer i staging area
git add .

# Lagre endringene som en commit med beskrivelse
git commit -m "Legg til navigasjonsmeny på forsiden"

# Se historikken over commits
git log --oneline

Samarbeid med GitHub:

# Last opp commits til GitHub
git push

# Hent og slå sammen endringer fra GitHub
git pull

Branching:

# Lag en ny branch
git branch ny-funksjon

# Bytt til branchen
git checkout ny-funksjon

# Eller lag og bytt i ett steg
git checkout -b ny-funksjon

# Slå sammen en branch inn i gjeldende branch
git merge ny-funksjon

Skriv gode commit-meldinger

Commit-meldinger er viktigere enn du tror. De er fremtidens dokumentasjon – når du (eller en annen) lurer på hvorfor en endring ble gjort, er commit-meldingen det første stedet å sjekke. En god commit-melding forklarer hva som ble endret og hvorfor.

Eksempler på dårlige commit-meldinger

git commit -m "fix"
git commit -m "endringer"
git commit -m "oppdatering"
git commit -m "ting"
git commit -m "asdfjkl"

Disse sier ingenting om hva som ble gjort eller hvorfor.

Eksempler på gode commit-meldinger

git commit -m "Fiks feil der kontaktskjema ikke sendte e-post"
git commit -m "Legg til responsivt design for mobilvisning"
git commit -m "Endre bakgrunnsfarge til morkebla etter kundens ønske"
git commit -m "Fjern utdatert jQuery-avhengighet og bruk vanilla JS"
git commit -m "Legg til passordvalidering med minimum 8 tegn"

Retningslinjer for commit-meldinger

1. Start med et verb i imperativ: «Legg til», «Fiks», «Endre», «Fjern», «Oppdater»
2. Vær spesifikk: «Fiks innloggingsfeil» er bedre enn «Fiks feil»
3. Hold det kort: Første linje bør være under 50-72 tegn
4. Skriv på norsk eller engelsk – vær konsistent gjennom prosjektet
5. Én commit per logisk endring: Ikke bland urelaterte endringer i samme commit

Brancher – parallelle utviklingslinjer

Branching er en av Gits kraftigste funksjoner. En branch lar deg jobbe på en funksjon eller en feilretting isolert fra resten av koden. Tenk på det som et parallelt univers der du kan gjøre hva du vil uten å påvirke den fungerende koden i main.

En typisk arbeidsflyt med brancher

1. Du er på main-branchen med fungerende kode
2. Du lager en ny branch: git checkout -b legg-til-bildegalleri
3. Du gjør endringer og committer dem i den nye branchen
4. Når funksjonen er ferdig og testet, merger du tilbake til main
5. Du sletter den gamle branchen (valgfritt)

main:     A---B---C---------F---G
                   \       /
bildegalleri:       D---E

Her representerer bokstavene commits. Branch bildegalleri ble opprettet fra commit C, fikk to egne commits (D og E), og ble merget tilbake til main som commit F.

Merge-konflikter

Noen ganger har to brancher endret de samme linjene i en fil. Da oppstår en merge-konflikt – Git kan ikke avgjøre hvilken versjon som er riktig og ber deg løse konflikten manuelt.

En merge-konflikt ser slik ut i filen:

<<<<<<< HEAD
<h1>Velkommen til Min Side</h1>
=======
<h1>Velkommen til Vår Nettside</h1>
>>>>>>> bildegalleri

Du må velge hvilken versjon du vil beholde (eller kombinere dem), fjerne konfliktmerkene (<<<, ===, >>>), og committe resultatet.

GitHub – samarbeidsplattformen

GitHub er en nettbasert plattform som bygger på Git og legger til samarbeidsverktøy. Mens Git er kommandolinjeverktøyet som kjører lokalt, er GitHub et nettsted der du kan:

- Lagre repositoriene dine i skyen
- Dele kode med andre (offentlig eller privat)
- Samarbeide gjennom pull requests
- Spore feil og oppgaver med Issues
- Vise prosjektets historikk visuelt
- Bygge en portefølje av prosjektene dine

Pull Requests – kodegjennomgang

En pull request (PR) er hjertet av samarbeid på GitHub. Når du har jobbet med en funksjon i en branch og vil slå den sammen med main, oppretter du en pull request. PR-en:

1. Viser alle endringene du har gjort (diff)
2. Lar teammedlemmer kommentere på spesifikke kodelinjer
3. Gir mulighet for diskusjon om designvalg
4. Kan kjøre automatiske tester
5. Krever godkjenning før sammenslåing

Arbeidsflyt med pull requests:

1. Lag en branch lokalt
2. Gjør endringer og commit
3. Push branchen til GitHub: git push -u origin min-branch
4. Opprett en Pull Request på GitHub
5. Teammedlemmer gjennomgår og kommenterer
6. Du gjør eventuelle endringer basert på tilbakemeldinger
7. PR-en godkjennes og merges inn i main

GitHub for skoleprosjekter

GitHub er et utmerket verktøy for skoleprosjekter:

- Læreren kan se kodehistorikken og hvem som har bidratt med hva
- Gruppemedlemmer kan jobbe på forskjellige deler samtidig
- Issues kan brukes som oppgaveliste (Kanban-lignende)
- README-filen fungerer som prosjektdokumentasjon
- GitHub Pages kan brukes til å publisere nettsider gratis

Ikke alle filer skal spores av Git. Opprett en .gitignore-fil i prosjektmappen for å fortelle Git hvilke filer og mapper den skal ignorere:

# .gitignore

# Node.js avhengigheter (installeres med npm install)
node_modules/

# Miljøvariabler (passord, API-nøkler)
.env

# OS-genererte filer
.DS_Store
Thumbs.db

# IDE-innstillinger
.vscode/
.idea/

# Kompilerte filer
dist/
build/

Aldri legg passord, API-nøkler eller personlige innstillinger i Git. Bruk .env-filer for hemmeligheter og legg dem i .gitignore.

📝Oppgave 8.4.1

Hva gjør kommandoen git commit -m "Legg til kontaktside"?

📝Oppgave 8.4.2

Hva er en branch i Git?

📝Oppgave 8.4.3

Hva er riktig rekkefølge for å lagre endringer i Git og laste dem opp til GitHub?

📝Oppgave 8.4.4

Hva er en pull request på GitHub?

📝Oppgave 8.4.5

Beskriv steg for steg hva du ville gjort for å:
(1) opprette et nytt Git-repository for et skoleprosjekt
(2) legge til en index.html-fil
(3) committe den, og
(4) laste den opp til et nytt repository på GitHub. Skriv de nødvendige Git-kommandoene.

📝Oppgave 8.4.6

Hva skjer når du prøver å merge to brancher som har endret de samme linjene i en fil?

📝Oppgave 8.4.7

Forklar forskjellen mellom Git og GitHub. Beskriv deretter en komplett arbeidsflyt der et team på tre elever samarbeider om et nettside-prosjekt ved hjelp av Git og GitHub, inkludert brancher og pull requests.

Oppsummering

I dette kapittelet har du lært:

- Git: distribuert versjonskontrollsystem.
- Repository: lager for prosjektets filer og historikk.
- Commit: lagrer en endring med melding.
- Branch og merge: parallelle utviklingslinjer som flettes sammen.
- GitHub og pull requests: samarbeid og kodegjennomgang.

Noekkelbegreper

Begrep	Forklaring
Git	Distribuert versjonskontrollsystem
Commit	Lagret endring med beskrivelse
Branch	Parallell utviklingslinje
Pull request	Foresporsel om kodegjennomgang og fletting

Dette kapitlet er skrevet av Anthropics toppmodeller (Claude Opus og Claude Fable) og er foreløpig ikke manuelt gjennomgått — kvalitetskontrollen gjøres av uavhengige KI-agenter, og innmeldte feil rettes fortløpende. Funnet en feil? Meld fra, så retter vi den. Les mer om hvordan innholdet lages.