Versjonskontroll

GitHub for generalister.

Sju begreper, tre bruksområder · Mai 2026

Skribenter, designere, lærere, ledere — alle har bruk for GitHub. Ingen har fortalt det på en måte som funker. Her er forsøket.

Du skriver et utkast. Du redigerer det. Du redigerer noe annet og angrer. Du finner ikke versjonen fra i går. Du har en mappe som heter «utkast endelig» og en annen som heter «utkast endelig 2» og en tredje som heter «endelig endelig».

Det finnes en bedre måte. Den heter GitHub.

Den er ikke bare for kode. Den brukes til bøker, artikler, notater, hele nettsider. Du kan også. Først må vi rydde i noen begreper.

Git og GitHub er ikke det samme

Statistikk-folka i SSB forklarer det enklest:

"Git er et verktøy installert på din lokale maskin som sporer endringer i koden din."Dapla-manualen, SSB
"GitHub er en skybasert plattform som fungerer som et felles lagringssystem der du kan dele og samarbeide med andre om kode."Dapla-manualen, SSB

Bytt ut «kode» med «tekst» eller «filer» — det funker likt. Git ligger på maskinen din og holder styr på endringene. GitHub er stedet på nettet der du kan lagre kopier og dele med andre.

Du trenger ikke begge. Du kan kjøre Git lokalt uten å lage en GitHub-konto. Men ved GitHub får du tre ting gratis: backup, historikk og et sted å samarbeide.

Hvorfor det er bedre enn en kopi-mappe

Hånda på hjertet — vi har alle den mappa. «Utkast 2024-03-18 final v3 EM_redigert.docx». Pro Git, læreboka som Git-folka selv har skrevet, sier det rett ut:

"Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone."Scott Chacon & Ben Straub, Pro Git

Tidsstemplete mapper er menneskets desperate forsøk på versjonskontroll. Det funker for små prosjekter. Det knekker så snart prosjektet vokser.

Med Git får du:

Pro Git er eksplisitt om at dette ikke bare gjelder programmerere:

"If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use."Scott Chacon & Ben Straub, Pro Git

Erstatt «graphic or web designer» med «forfatter, journalist, akademiker, terapeut, prest, lærer, advokat, designer». Argumentet holder.

Ordboka — sju ord du trenger

Du støter på de samme sju begrepene overalt. Her er den korte ordboka.

BegrepHva det betyrHverdags-bilde
repository (repo)et prosjekt med alt det inneholder og hele historienen perm
commitén lagring, et sjekkpunktsette inn ark i permen med dato på
branchet arbeidsspor parallelt med hovedsporeten sidehyllesperm til en kladd
pushflytte lokale commits opp til GitHubsende permen til skyen
pullhente endringer fra GitHub ned til deghente oppdateringer fra skyen
pull request (PR)forslag om å flette en branch inn i hovedsporetsi: «kan vi sette dette inn?»
mergeflette to grener sammensortere arkene tilbake i hovedpermen

Det er det. Når disse sju ordene gir mening, kan du jobbe med GitHub.

GUI eller kommandolinje?

Mange norske guider sender deg rett i terminalen. NTNUs Git-guide. UiO. Bekks workshop-materiale. Alle antar at du er komfortabel med svart skjerm og blinkende cursor.

For en generalist er det feil sted å begynne.

GitHub Desktop er et helt vanlig program med knapper og menyer. Det dekker det du trenger i 80 prosent av tilfellene.

"With GitHub Desktop, you can interact with GitHub using a GUI instead of the command line or a web browser. […] You can use GitHub Desktop to complete most Git commands from your desktop, such as pushing to, pulling from, and cloning remote repositories, attributing commits, and creating pull requests, with visual confirmation of changes."GitHub Docs

Det er en klar anbefaling for de første seks månedene. Begynn med GitHub Desktop. Når du føler du har sett alle knappene og lurer på hva som ligger bak — da kan du åpne terminalen. Mer om den diskusjonen i GUI eller terminal.

Tre konkrete bruksområder

Nok teori. Hva bruker du faktisk dette til som ikke-utvikler?

1. Versjonshistorikk for skrivingen din

Skriv i Obsidian, Typora, VS Code, eller hva du nå bruker for Markdown. Lagre filene i en mappe som er et Git-repository. Push til GitHub etter hver økt.

Vil du automatisere det? Obsidian-Git-pluginen gjør det for deg:

"A powerful community plugin for Obsidian.md that brings Git integration right into your vault. Automatically commit, pull, push, and see your changes — all within Obsidian."Vinzent03, obsidian-git README

Sett opp auto-commit hvert femte minutt. Du merker ingenting. Hele vaulten din er versjonert, backupet og søkbar på tvers av maskiner.

2. Nettsida di med Decap CMS

Hvis du har droppet WordPress og bygger med Astro eller en annen statisk sidegenerator, trenger redaktørene dine et UI å redigere i. Det er der Decap CMS kommer inn:

"Decap CMS is an open source content management system for your Git workflow that enables you to provide editors with a friendly UI and intuitive workflows."Decap CMS

Redaktøren ser et helt vanlig admin-grensesnitt. Bak kulissene gjør Decap commits til Git og lager pull requests. Redaktøren får aldri se ordet «commit» hvis vedkommende ikke vil.

Mer om dette oppsettet i Vi droppet WordPress og WordPress vs AI-nettside.

3. Claude som leser, skriver og foreslår

Når innholdet ditt ligger på GitHub, kan du la Claude jobbe direkte i repoet. Du kan be om endringer i en pull request. Du kan be den lese gjennom en hel bok og foreslå rettelser. Du kan be den foreslå nye seksjoner basert på det som allerede er der.

Et godt Claude Code-oppsett gir deg nettopp dette: AI-en blir en kollega som har full tilgang til hele prosjektet ditt, inkludert historikken — så den vet hva som har vært prøvd før. Mer om mønsteret i Claude Code-oppsett.

Det digitale hage-mønsteret

En tradisjon vi liker, særlig for skribenter. Maggie Appleton kaller det «digital garden»:

"A garden is something inbetween a personal blog and a wiki. It's a collection of evolving notes, essays, and ideas that aren't strictly organised by their publication date. […] They aren't refined or complete — posts can be published as half-finished thoughts that will grow and evolve over time."Maggie Appleton

Andy Matuschak kaller praksisen «work with the garage door up»:

"It's the opposite of the Twitter account which mostly posts announcements of finished work: it's Screenshot Saturday; it's giving a lecture about the problems you're pondering in the shower; it's thinking out loud about the ways in which your project doesn't work at all."Andy Matuschak

For å publisere halvferdige tanker trenger du noe som gjør halvferdig trygt. Versjonshistorikk gjør det trygt. Du kan publisere noe i dag, endre det i morgen, og hele historien er bevart. Ingenting går tapt.

Det er GitHubs gave til skribenter: friheten til å publisere før alt er ferdig.

Den ærlige advarselen

Det er noen fallgruver. Bedre at du vet om dem nå enn å snuble i dem senere.

Slik bruker du dette i praksis

  1. Lag konto på github.com. Gratis.
  2. Last ned GitHub Desktop. Logg inn der.
  3. Lag et nytt repository for skrive-prosjektet ditt. Klikk «Add new repository».
  4. Legg filene dine inn i mappa GitHub Desktop opprettet.
  5. Skriv en kort beskjed (en commit-melding): «første versjon». Klikk «Commit».
  6. Klikk «Publish repository» for å pushe det opp til GitHub.
  7. Gjenta steg 5 og 6 hver gang du har gjort noe verdt å lagre.
  8. Etter en uke: gå inn på github.com og se din egen historikk. Det er din digitale hage som har begynt å vokse.

Versjonskontroll er ikke for utviklere. Det er for alle som har skrevet «final v3 endelig» i et filnavn og kjent at det er feil.

← Tilbake til aifirma.no