8.3 Versjonskontroll og samarbeid | IT 2

Git, GitHub, branching og pull requests.

55 min

6 oppgaver

GitGitHubBranchingPull requests

Du leser den tradisjonelle versjonen

Din fremgang i kapitlet

0 / 6 oppgaver

Git er det dominerende verktøyet for versjonskontroll i moderne programvareutvikling. I dette kapittelet går vi dypere inn i avanserte Git-konsepter som branching, merging og pull requests – teknikker som er essensielle for effektivt teamarbeid.

Vi skal også se på GitHub Flow, en populær arbeidsflyt for kontinuerlig leveranse.

Branching (Forgreining)

En branch er en parallell versjon av kodebasen der du kan jobbe isolert uten å påvirke hovedversjonen (main/master).

Vanlige branching-strategier:

Feature branches:
- Én branch per ny feature
- Navnekonvensjon: feature/brukerprofil, feature/betaling
- Merges til main når ferdig

Bugfix branches:
- Navnekonvensjon: bugfix/login-crash, fix/null-pointer

Release branches:
- Forbereder en ny versjon til produksjon
- Navnekonvensjon: release/v2.1.0

Hotfix branches:
- Kritiske feil i produksjon som må fikses umiddelbart
- Navnekonvensjon: hotfix/security-patch

Grunnleggende Git branch-kommandoer:

# Opprett og bytt til ny branch
git checkout -b feature/ny-funksjon

# Vis alle branches
git branch -a

# Bytt til eksisterende branch
git checkout main

# Slett branch (etter merge)
git branch -d feature/gammel-funksjon

# Tvungen sletting (vær forsiktig!)
git branch -D feature/forkastet-ide

Merging

Merging kombinerer endringer fra én branch inn i en annen:

Fast-forward merge:
Når target branch ikke har nye commits siden branching:

git checkout main
git merge feature/enkel-endring

Three-way merge:
Når begge branches har nye commits:
- Git lager en merge commit som kombinerer endringene

Merge conflicts:
Oppstår når samme linje er endret i begge branches:

git merge feature/konflikt
# CONFLICT (content): Merge conflict in app.py

# Åpne app.py og finn:
<<<<<<< HEAD
def greeting():
    return "Hei"
=======
def greeting():
    return "Hello"
>>>>>>> feature/konflikt

Løse konflikten:
1. Rediger filen manuelt, velg riktig versjon (eller kombiner)
2. Fjern conflict markers (<<<<<<<, =======, >>>>>>>)
3. git add app.py
4. git commit

Rebase (alternativ til merge)

Rebase flytter dine commits til toppen av en annen branch:

git checkout feature/min-branch
git rebase main

Fordel: Lineær commit-historikk (renere enn merge commits)
Ulempe: Omskriver historikk (ikke bruk på public branches!)

Pull Requests (PR) / Merge Requests (MR)

En pull request er en forespørsel om å merge din branch til main:

Typisk PR-flyt:
1. Lag feature branch og commit endringer
2. Push branch til GitHub: git push origin feature/ny-funksjon
3. Åpne PR på GitHub
4. Be om code review fra teammedlemmer
5. Diskuter, gjør endringer basert på feedback
6. Når godkjent: Merge til main

God PR-praksis:
- Hold PRs små (< 400 linjer kode)
- Skriv beskrivende tittel og oppsummering
- Link til issue/ticket
- Inkluder screenshots for UI-endringer
- Sørg for at CI/CD-tester passerer

GitHub Flow

En enkel, branch-basert arbeidsflyt:

1. Main er alltid deploybar – All kode i main er produksjonsklar
2. Lag descriptive branches – feature/user-authentication
3. Commit ofte – Små, fokuserte commits
4. Åpne PR tidlig – Få tilbakemelding underveis
5. Diskuter og gjennomgå – Code review før merge
6. Merge og deploy – Automatisk deploy til produksjon etter merge

Git best practices:

- Commit ofte, push daglig
- Skriv gode commit messages: "Legg til validering av e-post", ikke "fix"
- Pull før du push (unngå konflikter)
- Bruk .gitignore for å ekskludere autogenererte filer
- ALDRI commit hemmeligheter (API-nøkler, passord)
- Bruk meaningful branch names

✏️Eksempel: Feature branch workflow

Scenario: Du skal legge til en "Glemt passord"-funksjon i en Flask-app.

Steg 1: Opprett branch

# Sørg for at main er oppdatert
git checkout main
git pull origin main

# Lag ny feature branch
git checkout -b feature/forgot-password

Steg 2: Gjør endringer

# Rediger nødvendige filer
# app.py, templates/forgot_password.html, etc.

# Commit endringer
git add app.py templates/forgot_password.html
git commit -m "Legg til forgot password-funksjonalitet

- Nytt endepunkt /forgot-password
- E-postvalidering
- Send reset-lenke på e-post
- Testdekning: test_forgot_password.py"

Steg 3: Push og åpne PR

# Push branch til GitHub
git push origin feature/forgot-password

# Gå til GitHub og åpne Pull Request
# Tittel: "Legg til glemt passord-funksjonalitet"
# Beskrivelse:
# "Implementerer forgot password-flow:
# - Bruker oppgir e-post
# - Mottar reset-lenke
# - Kan sette nytt passord
#
# Closes #45"

Steg 4: Code review og feedback
Kollega kommenterer:
"Bør vi ha rate limiting på /forgot-password for å forhindre spam?"

Du gjør endringer:

# Legg til rate limiting
git add app.py
git commit -m "Legg til rate limiting på forgot password (max 3/time)"
git push origin feature/forgot-password
# PR oppdateres automatisk

Steg 5: Merge
Etter godkjenning:

# På GitHub: Klikk "Merge pull request"
# Eller via kommandolinje:
git checkout main
git merge feature/forgot-password
git push origin main

# Slett branch (opprydding)
git branch -d feature/forgot-password
git push origin --delete feature/forgot-password

✏️Eksempel: Løse merge conflict

Scenario: To utviklere har endret samme fil.

Developer A (på main):

# config.py
DATABASE_URL = "postgresql://localhost/myapp"
DEBUG = False

Developer B (på feature/ny-database):

# config.py
DATABASE_URL = "postgresql://localhost/testdb"
DEBUG = True

Developer B prøver å merge:

git checkout main
git pull  # Får Developer A's endringer
git checkout feature/ny-database
git merge main

# Output:
Auto-merging config.py
CONFLICT (content): Merge conflict in config.py
Automatic merge failed; fix conflicts and then commit the result.

config.py ser nå slik ut:

<<<<<<< HEAD
DATABASE_URL = "postgresql://localhost/testdb"
DEBUG = True
=======
DATABASE_URL = "postgresql://localhost/myapp"
DEBUG = False
>>>>>>> main

Løsning:
Developer B diskuterer med Developer A og blir enige om riktig løsning:

# config.py (konflikt løst)
DATABASE_URL = "postgresql://localhost/myapp"
DEBUG = True  # Beholder DEBUG=True for testing

Fullfør merge:

git add config.py
git commit -m "Merge main og løs konflikt i config.py"
git push origin feature/ny-database

Oppgave 1 (Flervalg)
Hva er formålet med en feature branch?

A) Å publisere nye versjoner til produksjon
B) Å jobbe på ny funksjonalitet isolert fra main
C) Å fikse kritiske bugs i produksjon
D) Å slette gammel kode

Oppgave 2 (Flervalg)
Hva skjer når du kjører git merge feature/ny-funksjon fra main-branchen?

A) Main slettes og erstattes av feature/ny-funksjon
B) Endringer fra feature/ny-funksjon kombineres med main
C) Feature/ny-funksjon slettes
D) Alle commits i main forsvinner

Oppgave 3
Forklar kort hva en merge conflict er, og hvordan du løser den.

Oppgave 4
Skriv Git-kommandoene for å:
a) Opprette en ny branch kalt feature/login
b) Bytte til denne branchen
c) Merge den inn i main
d) Slette branchen etter merge

Oppgave 5
Hva er forskjellen mellom git merge og git rebase?

Oppgave 6
Nevn tre ting som kjennetegner en god pull request.

Oppgave 7
Forklar kort hva GitHub Flow er.

Oppgave 8
Hvorfor er det viktig å holde pull requests små (under 400 linjer)?

// --- Samleoppgaver ---

Samleoppgave 1
Du jobber på et team med 5 utviklere. Dere bruker GitHub Flow. Prosjektet er en nettbutikk.

a) Beskriv steg-for-steg hvordan du ville implementert en ny feature: "Kundeanmeldelser av produkter".
b) Hva gjør du hvis en kollega allerede har endret samme fil du jobber på?
c) Når i prosessen bør du be om code review?
d) Hva gjør du hvis CI/CD-testene feiler på din PR?

Samleoppgave 2
Et team opplever følgende situasjon:
- Developer A har jobbet på feature/search i 2 uker
- Main har fått 50 nye commits i mellomtiden
- Developer A prøver å merge, får 15 merge conflicts

a) Hvorfor oppstod så mange konflikter?
b) Forklar hvordan Developer A kunne unngått dette problemet.
c) Beskriv to strategier for å løse situasjonen nå.
d) Hvilke team-rutiner kunne forebygget problemet?

Oppsummering

I dette kapittelet har du lært:

- Versjonskontroll: sporer endringer og samarbeid.
- Brancher: parallelle utviklingslinjer.
- Merge og konflikter: flette sammen og løse konflikter.
- Feature branch workflow: vanlig arbeidsflyt.
- Samarbeid: koordinere arbeid mellom utviklere.

Noekkelbegreper

Begrep	Forklaring
Branch	Parallell utviklingslinje i Git
Merge	Å flette sammen brancher
Merge-konflikt	Motstridende endringer som må løses manuelt

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.