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 nokon gong lagra filer med namn som prosjekt_v1.html, prosjekt_v2_ENDELIG.html, prosjekt_v3_ENDELIG_NY.html? Eller kanskje du har gjort ei endring som øydela noko, og du innsåg at du ikkje hadde ein kopi av den førre versjonen? Versjonskontroll løyser desse problema.

Git er eit versjonskontrollsystem som held styr på alle endringar du gjer i prosjektet ditt. Det er som ei tidsmaskin for koden din – du kan sjå heile endringshistorikken, gå tilbake til ein kva som helst tidlegare versjon, og samarbeide med andre utan å overskrive arbeidet til kvarandre.

Git er det mest brukte verktøyet i profesjonell programvareutvikling. Uansett om du jobbar åleine eller i eit team, er Git ei ferdigheit du treng. I dette kapittelet lærer du dei grunnleggjande konsepta og kommandoane du treng for å komme i gang.

Git

Git er eit distribuert versjonskontrollsystem som sporar endringar i filer og koordinerer arbeid mellom fleire personar. Git blei utvikla av Linus Torvalds i 2005 for å handtere utviklinga av Linux-kjernen. Distribuert betyr at kvar utviklar har ein komplett kopi av heile prosjekthistorikken, slik at du kan jobbe offline og ikkje er avhengig av ein sentral server. Git er gratis, open kjeldekode, og blir brukt av alt frå enkeltpersonprosjekt til dei største programvareprosjekta i verda.

Kvifor versjonskontroll er uunnverleg

Versjonskontroll gir deg fleire superkrefter:

1. Historikk: Kvar endring du gjer blir lagra med ei skildring. Du kan sjå nøyaktig kva som blei endra, når og av kven. Dette er uvurderleg når du lurer på kvifor koden ser ut som han gjer, eller når noko plutseleg sluttar å fungere.

2. Angre-funksjon: Gjorde du ein feil? Du kan gå tilbake til ein kva som helst tidlegare versjon av prosjektet. Inga endring er permanent – du kan alltid rulle tilbake.

3. Parallell utvikling: Med branchar kan du jobbe på ein ny funksjon utan å forstyrre den fungerande koden. Når funksjonen er ferdig, slår du han saman med hovudkoden.

4. Samarbeid: Fleire personar kan jobbe på det same prosjektet samtidig utan å overskrive endringane til kvarandre. Git held styr på kven som endra kva og hjelper med å slå saman arbeidet.

5. Eksperimentering: Du kan prøve ut idéar i ein eigen branch utan risiko. Fungerer det? Slå det saman. Fungerer det ikkje? Slett branchen og ingen skade er gjort.

6. Sikkerheitskopi: Når du dyttar (push) koden til GitHub, har du ein sikkerheitskopi i skya. Sjølv om datamaskinen din døyr, er koden trygg.

Dei viktigaste Git-omgrepa

Før vi ser på kommandoar, lat oss forstå dei sentrale omgrepa:

Repository (repo)

Eit repository er prosjektmappa di med Git aktivert. Det inneheld alle prosjektfilene dine pluss ei skjult .git-mappe som lagrar heile endringshistorikken. Du kan ha eit lokalt repo på maskinen din og eit eksternt (remote) repo på GitHub.

Working Directory, Staging Area og Repository

Git har tre «område» for filer:

1. Working Directory: Mappa du jobbar i. Endringar her er ikkje lagra i Git enno.
2. Staging Area (Index): Eit mellomsteg der du vel kva endringar som skal inkluderast i neste commit. Du legg filer til staging med git add.
3. Repository: Den permanente historikken. Når du køyrer git commit, blir endringane frå staging area lagra som eit nytt punkt i historikken.

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

Commit

Ein commit er eit augneblinksbilete av prosjektet ditt på eit bestemt tidspunkt. Tenk på det som eit lagringspunkt i eit spel – du kan alltid gå tilbake hit.

Branch

Ein branch er ei parallell utviklingslinje. Hovudbranchen heiter main. Når du vil lage ein ny funksjon, lagar du ein ny branch, gjer endringane der, og mergar tilbake til main når du er ferdig.

✏️Dei viktigaste Git-kommandoane

Her er dei grunnleggjande Git-kommandoane du treng 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"

Dagleg 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-meldingar

Commit-meldingar er viktigare enn du trur. Dei er dokumentasjonen til framtida – når du (eller ein annan) lurer på kvifor ei endring blei gjord, er commit-meldinga den første staden å sjekke. Ei god commit-melding forklarar kva som blei endra og kvifor.

Døme på dårlege commit-meldingar

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

Desse seier ingenting om kva som blei gjort eller kvifor.

Døme på gode commit-meldingar

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-meldingar

1. Start med eit verb i imperativ: «Legg til», «Fiks», «Endre», «Fjern», «Oppdater»
2. Ver spesifikk: «Fiks innloggingsfeil» er betre enn «Fiks feil»
3. Hald det kort: Første linje bør vere under 50-72 teikn
4. Skriv på norsk eller engelsk – ver konsistent gjennom prosjektet
5. Éin commit per logisk endring: Ikkje bland urelaterte endringar i same commit

Branchar – parallelle utviklingslinjer

Branching er ein av dei kraftigaste funksjonane til Git. Ein branch lèt deg jobbe på ein funksjon eller ei feilretting isolert frå resten av koden. Tenk på det som eit parallelt univers der du kan gjere kva du vil utan å påverke den fungerande koden i main.

Ein typisk arbeidsflyt med branchar

1. Du er på main-branchen med fungerande kode
2. Du lagar ein ny branch: git checkout -b legg-til-bildegalleri
3. Du gjer endringar og committar dei i den nye branchen
4. Når funksjonen er ferdig og testa, mergar du tilbake til main
5. Du slettar den gamle branchen (valfritt)

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

Her representerer bokstavane commits. Branch bildegalleri blei oppretta frå commit C, fekk to eigne commits (D og E), og blei merga tilbake til main som commit F.

Merge-konfliktar

Nokre gonger har to branchar endra dei same linjene i ei fil. Då oppstår ein merge-konflikt – Git kan ikkje avgjere kva versjon som er riktig og ber deg løyse konflikten manuelt.

Ein merge-konflikt ser slik ut i fila:

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

Du må velje kva versjon du vil behalde (eller kombinere dei), fjerne konfliktmerka (<<<, ===, >>>), og committe resultatet.

GitHub – samarbeidsplattforma

GitHub er ei nettbasert plattform som byggjer på Git og legg til samarbeidsverktøy. Medan Git er kommandolinjeverktøyet som køyrer lokalt, er GitHub eit nettstad der du kan:

- Lagre repositoria dine i skya
- Dele kode med andre (offentleg eller privat)
- Samarbeide gjennom pull requests
- Spore feil og oppgåver med Issues
- Vise historikken til prosjektet visuelt
- Byggje ein portefølje av prosjekta dine

Pull Requests – kodegjennomgang

Ein pull request (PR) er hjartet av samarbeid på GitHub. Når du har jobba med ein funksjon i ein branch og vil slå han saman med main, opprettar du ein pull request. PR-en:

1. Viser alle endringane du har gjort (diff)
2. Lèt teammedlemmer kommentere på spesifikke kodelinjer
3. Gir høve for diskusjon om designval
4. Kan køyre automatiske testar
5. Krev godkjenning før samanslå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 skuleprosjekt

GitHub er eit utmerkt verktøy for skuleprosjekt:

- Læraren kan sjå kodehistorikken og kven som har bidrege med kva
- Gruppemedlemmer kan jobbe på ulike delar samtidig
- Issues kan brukast som oppgåveliste (Kanban-liknande)
- README-fila fungerer som prosjektdokumentasjon
- GitHub Pages kan brukast til å publisere nettsider gratis

Ikkje alle filer skal sporast av Git. Opprett ei .gitignore-fil i prosjektmappa for å fortelje Git kva filer og mapper han 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øklar eller personlege innstillingar i Git. Bruk .env-filer for løyndomar og legg dei i .gitignore.

📝Oppgave 8.4.1

Kva gjer kommandoen git commit -m "Legg til kontaktside"?

📝Oppgave 8.4.2

Kva er ein branch i Git?

📝Oppgave 8.4.3

Kva er riktig rekkefølgje for å lagre endringar i Git og laste dei opp til GitHub?

📝Oppgave 8.4.4

Kva er ein pull request på GitHub?

📝Oppgave 8.4.5

Skildr steg for steg kva du ville gjort for å:
(1) opprette eit nytt Git-repository for eit skuleprosjekt
(2) leggje til ei index.html-fil
(3) committe ho, og
(4) laste ho opp til eit nytt repository på GitHub. Skriv dei nødvendige Git-kommandoane.

📝Oppgave 8.4.6

Kva skjer når du prøver å merge to branchar som har endra dei same linjene i ei fil?

📝Oppgave 8.4.7

Forklar skilnaden mellom Git og GitHub. Skildr deretter ein komplett arbeidsflyt der eit team på tre elevar samarbeider om eit nettside-prosjekt ved hjelp av Git og GitHub, inkludert branchar og pull requests.

Oppsummering

I dette kapittelet har du lært:

- Git: distribuert versjonskontrollsystem.
- Repository: lager for filene og historikken til prosjektet.
- Commit: lagrar ei endring med melding.
- Branch og merge: parallelle utviklingslinjer som blir fletta saman.
- GitHub og pull requests: samarbeid og kodegjennomgang.

Nøkkelomgrep

Begrep	Forklaring
Git	Distribuert versjonskontrollsystem
Commit	Lagra endring med skildring
Branch	Parallell utviklingslinje
Pull request	Førespurnad 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.