GitHub for generalister
Skribenter, designere, lærere og ledere har alle bruk for GitHub. Ingen har fortalt deg 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.
Kort svar: trenger du dette?
GitHub er et sted på nettet som husker alle versjonene av filene dine. Nei, du trenger det ikke for å komme i gang med boten. Du trenger det den dagen du vil kunne angre, eller ha en sikkerhetskopi av noe du har brukt uker på.
Det fine er at du kan la boten gjøre det. Du trenger ikke lære kommandoene. Du kan si:
«Lagre en versjon av prosjektet mitt nå, og skriv en kort beskrivelse av hva som er nytt siden sist.»
Og når noe går galt:
«Det du gjorde i stad ble feil. Gå tilbake til forrige versjon, og fortell meg i vanlige ord hva du gjorde.»
Resten av saken er for deg som vil forstå hva som skjer bak, eller som vil sitte med knappene selv. Først 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», så funker det 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
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 nødløsningen alle prøver først. Det funker for små prosjekter. Det knekker så snart prosjektet vokser.
Med Git får du:
- Full historie. Hver lagring er et sjekkpunkt du kan rulle tilbake til.
- Sammenligning. Hva ble lagt til, hva ble fjernet, hvem gjorde hva, og når.
- Samarbeid. To som jobber samtidig på samme dokument, og endringene flettes inn.
- Backup. Hvis maskinen din ryker, ligger alt på GitHub.
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» eller «lærer». Argumentet holder.
Ordboka: sju ord du trenger
Du støter på de samme sju begrepene overalt. Her er den korte ordboka.
| Begrep | Hva det betyr | Hverdags-bilde |
|---|---|---|
| repository (repo) | et prosjekt med alt det inneholder og hele historien | en perm |
| commit | én lagring, et sjekkpunkt | sette inn ark i permen med dato på |
| branch | et arbeidsspor parallelt med hovedsporet | en egen perm for kladden |
| push | flytte lokale commits opp til GitHub | sende permen til skyen |
| pull | hente endringer fra GitHub ned til deg | hente oppdateringer fra skyen |
| pull request (PR) | forslag om å flette en branch inn i hovedsporet | si: «kan vi sette dette inn?» |
| merge | flette to grener sammen | sortere 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, fra universiteter og konsulenthus, sender deg rett i terminalen. De 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, kan du åpne terminalen. Mer om den diskusjonen i GUI eller terminal. Hvordan vi selv setter opp arbeidet, står i Claude Code-oppsettet vårt.
To konkrete bruksområder
Nok teori. Hva bruker du dette til som ikke-utvikler?
1. Versjonshistorikk for skrivingen din
Skriv i det du vil. Lagre filene i en mappe som er et prosjekt i Git, og last den opp til GitHub etter hver økt.
Vil du slippe å tenke på det? Be boten sette det opp slik at hver økt lagres av seg selv. Du merker ingenting, og hele mappa er sikkerhetskopiert.
2. 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 prosjektet. Du kan be om endringer som du godkjenner før de blir med. 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.
Da blir AI-en en kollega med tilgang til hele prosjektet ditt, også historikken, så den vet hva som har vært prøvd før.
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 og endre det i morgen, og hele historien er bevart. Det er GitHubs gave til skribenter: friheten til å publisere før alt er ferdig.
To ting som overrasker nybegynnere
- Privat eller offentlig. Du kan ha private prosjekter gratis. Du trenger ikke dele med verden. Mange tror det motsatte.
- Innlogging. GitHub tar ikke lenger passord for å lagre fra maskinen din. GitHub Desktop ordner det for deg når du logger inn første gang. Står du fast, spør boten.
Hva du kan prøve i morgen
- Lag konto på github.com. Gratis.
- Last ned GitHub Desktop og logg inn der. Det er et vanlig program med knapper.
- Velg en mappe med noe du skriver. La GitHub Desktop gjøre den til et prosjekt, og trykk «Commit» med en kort beskjed som «første versjon».
- Trykk «Publish» for å legge en kopi på nettet.
- Eller hopp over alt dette og be boten gjøre det for deg, med setningen øverst.
- Etter en uke: gå inn på github.com og se historikken din. Det er den digitale hagen din som har begynt å vokse.
Du trenger ikke kunne Git. Du trenger bare å vite at du kan gå tilbake.