Bygg noe Mai 2026

GitHub for generalister

Skribenter, designere, lærere, ledere — alle har bruk for GitHub. Ingen har fortalt dere det på en måte som funker. Vi prøver.

Du skriver et utkast og redigerer det. Så redigerer du noe annet, angrer, og 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. Det kan du 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 med 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 egen perm for kladden
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?

De norske Git-guidene vi har lest — universitetenes og konsulenthusenes — sender deg rett i terminalen. Alle antar at du er komfortabel med svart skjerm og blinkende markør.

For en generalist er det feil sted å begynne.

GitHub Desktop er et helt vanlig program med knapper og menyer. Det dekker det meste av det en generalist trenger.

“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

Vi begynte der selv. Når 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 til 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, sikkerhetskopiert og søkbar på tvers av maskiner.

2. Nettsida di med et Git-basert CMS

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

“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 blir hver lagring en commit i Git. Redaktøren får aldri se ordet «commit» hvis vedkommende ikke vil.

Denne sida kjører Sveltia CMS, som bygger på samme prinsipp. Hvordan det ble satt opp, står i Slik fikk vi et CMS på en time. Valget av stack står i artikkelen om WordPress i 2026.

3. Claude som leser, skriver og foreslår

Har du ikke brukt Claude før, begynn med AI for nybegynnere. 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 hele 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.

Fem ting som stopper nybegynnere

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.

Kilder


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