En unik måte å håndtere skriveprosjekter på: Bruk av Git og GitHub
Det finnes mange ulike metoder for å organisere og arkivere dine skriveprosjekter. Enkelte foretrekker skybaserte løsninger som Dropbox eller nettbaserte tekstbehandlere som Google Docs, mens andre sverger til skrivebordsapplikasjoner som Microsoft Word. Jeg har imidlertid funnet en annen tilnærming som fungerer utmerket for meg – nemlig bruk av GitHub.
GitHub: Mer enn bare for kode
Jeg benytter meg av Git og GitHub for å lagre og få tilgang til alt jeg produserer av tekst. Git er et robust verktøy som lar deg spore endringer i dokumentene dine, og i tillegg kan du laste opp arbeidet ditt til GitHub på et øyeblikk. Det er også raskt og enkelt å laste ned prosjektene dine til en annen enhet.
For de som ikke er kjent med GitHub, er det en global plattform som hovedsakelig brukes til å lagre og administrere åpen kildekode. Ved første øyekast kan det virke som et uvanlig sted å lagre skrivearbeid, men det er det faktisk ikke. Tross alt består både kode og tekster av linjer med informasjon.
Rundt 2013 begynte GitHub å promotere bruken av plattformen for alle typer informasjon, ikke bare kode. Selv om GitHub fortsatt har sitt utgangspunkt i koding, er det flere som bruker plattformen for å lagre skriveprosjekter og andre ikke-kodende oppgaver. Som eksempler har vi en person som brukte Git og GitHub til å skrive en instruksjonsbok og en annen som skrev en roman. En raskt søk på internett vil vise deg et mangfold av innovative bruksområder for GitHub.
Hva er Git og GitHub?
Informasjonsdelen av et GitHub-depot.
Git er et åpen kildekode-program utviklet av Linus Torvalds, kjent fra Linux. Git registrerer endringer i dokumenter og legger til rette for at flere personer kan samarbeide om samme dokument fra forskjellige steder. Teknisk sett kalles det et distribuert versjonskontrollsystem (VCS). I stedet for å automatisk lagre versjoner av dokumentene dine med jevne mellomrom, lagrer Git endringer kun når du eksplisitt ber om det.
Dine dokumenter danner et depot, eller «repo», som er en fancy betegnelse for prosjektmappen din. Tenk på dokumentmappen din i Windows; den kunne ha vært et depot om du brukte Git til å administrere den (jeg anbefaler det likevel ikke som en start).
Når du lagrer endringer i dokumentene dine med Git, kalles dette en «commit». En commit er et øyeblikksbilde av de siste endringene du har gjort i et dokument. Hver commit tildeles en unik ID, som er en lang serie av tall og bokstaver.
Hvis du henter en tidligere commit ved hjelp av ID-en, får du ikke se hele prosjektet slik du ville gjort i for eksempel Word sin dokumenthistorikk. Du vil kun se de siste endringene som ble gjort i commiten. Det betyr ikke at hele prosjektet ikke er registrert. Du kan faktisk slette alt du skriver fra prosjektmappen og likevel hente den nyeste versjonen tilbake ved hjelp av noen få Git-kommandoer. Du kan til og med gå tilbake og se hvordan prosjektet så ut for en uke eller seks måneder siden.
Du kan også legge til meldinger til hver commit, noe som er svært nyttig. Hvis du for eksempel skriver noe du er usikker på om du vil beholde, er det bare å lage en commit. Seksjonen vil da være bevart i commit-loggen, selv om du sletter den fra prosjektet senere.
Git fungerer best gjennom kommandolinjen, noe som både er en fordel og en ulempe. Kommandolinjen er effektiv for å opprette commits og laste opp endringer, men den er ikke ideell for å se en oversikt over commit-historikken.
Dette er grunnen til at mange foretrekker GitHub – en populær nettjeneste som tilbyr et brukervennlig nettgrensesnitt for dine Git-depoter. På GitHub kan du enkelt se tidligere commits og laste ned tekstene dine til flere datamaskiner.
Sammen gir Git og GitHub meg detaljert kontroll over versjonshistorikken min. Det gjør det også enkelt å skrive på hvilken som helst maskin som kan kjøre en Bash-kommandolinje, som i dag inkluderer Windows, Mac, Linux og Chrome OS.
Enkelt med rene tekstfiler
Git kan hjelpe med å redde skrivingen din, men det kan ikke gjøre deg til en bedre forfatter.
Git og GitHub støtter stort sett alle filtyper for skriving, men det fungerer best med ren tekst. Hvis du skriver i Microsoft Word, vil det fungere, men du vil ikke kunne se tidligere commits i kommandolinjen eller i GitHub. I stedet må du hente en tidligere commit i kommandolinjen (kalt en «checkout») og deretter åpne Word-filen. Word-filen vil da se ut akkurat som den gjorde da du opprettet den første commiten, og du kan gå tilbake til gjeldende versjon med en ny kommando.
Dersom du bruker Scrivener, vil også dette fungere. Scrivener lagrer filer som tekst, og tidligere commits vil vises både i GitHub og i kommandolinjen. Imidlertid lagrer Scrivener også data som er viktige for programmet, men ikke for deg som bruker. Hver commit vil derfor inneholde en del «søppel» som gjør det vanskelig å lese.
Jeg foretrekker rene tekstfiler fordi det er alt du egentlig trenger for å sette sammen ord, spesielt i de første utkastene dine.
Komme i gang med Git
La oss gå litt mer i detalj om hvordan alt dette fungerer. Vi begynner med datamaskinen din og beveger oss deretter over til skyen med GitHub.
For å komme i gang trenger du terminalprogrammet på macOS eller Linux. Hvis du bruker Windows 10, må du installere Ubuntu eller en annen Linux-distribusjon via Windows Subsystem for Linux (WSL), noe som er ganske enkelt. Du kan sjekke ut en veiledning for å installere Linux Bash-skallet på Windows 10. Alternativt, hvis du har en eldre versjon av Windows, kan du bruke Cygwin for å få et Bash-skall.
Åpne terminalen og naviger til mappen du vil bruke som et Git-depot. La oss si at vi har en mappe kalt «MyNovel» i Dokumenter-mappen. Det er viktig å unngå mellomrom i navnet på Git-repoen, da dette vil gjøre det enklere å bruke Bash-kommandoer.
Naviger deretter til MyNovel-mappen i terminalen. For å gjøre dette i Windows 10 er kommandoen:
cd /mnt/c/Users/[DittBrukernavn]/Documents/MyNovel
Husk at alle WSL-kommandoer som samhandler med filer lagret i Windows må bruke /mnt/. Legg også merke til at «c» indikerer stasjonen du er på. Hvis filene dine er på en «D:/»-stasjon, bruker du /d/.
For macOS og Linux er kommandoen mye enklere:
cd ~/Documents/MyNovel
Fra nå av er kommandoene de samme for alle operativsystemer.
Nå må vi initialisere MyNovel-mappen som et Git-depot. Denne kommandoen fungerer uansett om du akkurat har startet en ny roman eller allerede har lagrede filer i mappen:
git init
Mappen din er nå et Git-depot. Du kan verifisere dette ved å skrive følgende:
ls -a
Denne kommandoen ber datamaskinen om å vise alt i den gjeldende mappen, inkludert skjulte elementer. Du skal se noe som heter «.git» øverst på listen. Den skjulte «.git»-mappen er der versjonshistorikken lagres. Du trenger aldri å åpne denne mappen, men den må være der.
Den første commiten
Før vi gjør vår første commit, må Git kjenne navnet ditt og e-postadressen din. Denne informasjonen brukes til å identifisere hvem som har gjort commiten, og den er inkludert i commit-loggen. Dette har i praksis ingen betydning siden forfattere som regel jobber alene, men Git krever det likevel.
For å angi e-post og navn, skriver du følgende:
git config --global user.email "[Din e-post]" git config --global user.name "[Ditt navn]"
Det er alt. La oss nå gå videre til den første commiten.
La oss anta at det finnes tre dokumenter i «MyNovel»-mappen: «Chapter1», «Chapter2» og «Chapter3». For å lagre endringer må vi fortelle Git å spore disse filene. Dette gjør vi ved å skrive:
git add .
Punktumet forteller Git at den skal overvåke alle uregistrerte filer i mappen. Denne kommandoen forteller også Git at den skal forberede alle overvåkede filer som er endret. Denne prosessen kalles å «stage» filer for commit.
I dette tilfellet trenger vi egentlig ikke «staging», men det kan være nyttig i visse situasjoner. Hvis du for eksempel har gjort endringer i både kapittel 2 og 3, men bare ønsker å commit endringene i kapittel 2, vil du «stage» kapittel 2 med følgende kommando:
git add Chapter2.doc
Dette forteller Git at du ønsker å gjøre endringene i kapittel 2 klare for commit, men ikke endringene i kapittel 3.
Nå er det tid for den første commiten:
git commit -m "Dette er min første commit."
«-m» er et flagg som forteller Git at du ønsker å opprette en commit og legge ved en melding, som du ser mellom anførselstegnene. Jeg liker å bruke commit-meldingene mine til å registrere antall ord. Jeg bruker dem også til å notere spesiell informasjon, for eksempel: «Denne commiten inkluderer et intervju med administrerende direktør i Acme Widgets.»
Hvis jeg skriver en historie, kan jeg for eksempel legge til en melding som sier: «Denne commiten har med den nye scenen der hunden løper.» Nyttige meldinger gjør det enklere å finne frem i commit-loggen senere.
Nå som vi har begynt å spore dokumentene våre, er det på tide å overføre tekstene våre til skyen med GitHub. Jeg bruker GitHub som en ekstra sikkerhetskopi, et pålitelig sted å se dokumentendringene mine, og en måte å få tilgang til arbeidet mitt fra flere datamaskiner.
Komme i gang med GitHub
Du fyller ut skjemaet for å opprette et nytt GitHub-depot.
Først må du opprette en gratis konto på GitHub. Du trenger ikke en betalt konto for å opprette private arkiver, men du kan kun samarbeide med opptil tre personer på et privat repo. Hvis du har et team på fem eller flere som jobber med en artikkel, må du registrere deg for en Pro-konto (ca. $7 per måned).
Når du har opprettet kontoen din, la oss lage et nytt depot. Logg deg på kontoen din og gå til https://github.com/new.
Det første vi må gjøre er å gi depotet et navn. Du kan bruke samme navn som du har brukt for mappen på datamaskinen din. Under «Repository Name» skriver du «MyNovel».
«Beskrivelsen» er valgfri, men jeg liker å bruke den. Du kan skrive noe som «Min fantastiske nye roman om en gutt, en jente og hunden deres», osv.
Velg deretter alternativknappen «Privat», men ikke kryss av boksen som heter «Initialiser dette depotet med en README». Vi ønsker ikke å gjøre dette, da vi allerede har et depot på datamaskinen vår. Hvis vi oppretter en README-fil nå, vil det gjøre ting mer komplisert.
Klikk deretter på «Opprett arkiv». Kopier URL-en under «Rask oppsett – hvis du har gjort denne typen ting før». Den skal se omtrent slik ut:
https://github.com/[Ditt GitHub brukernavn]/MyNovel.git
Nå går vi tilbake til skrivebordet og vår kjære kommandolinje.
Overfør skrivebord-repo til skyen
Bruke Git på kommandolinjen.
Første gang du kobler et depot til GitHub, må du bruke noen få spesielle kommandoer. Den første er:
git remote add origin https://github.com/[Ditt GitHub brukernavn]/MyNovel.git
Dette forteller Git at et eksternt depot er opprinnelsen til «MyNovel». URL-en peker deretter Git mot den eksterne opprinnelsen. Ikke bekymre deg for mye over begrepet «opprinnelse»; det er bare en konvensjon. Du kan kalle det «fluffy» om du vil, opprinnelsen er bare enklere siden det er den vanligste måten å bruke Git på.
Når du laster opp nye endringer med Git, kalles det en «push». Når du laster ned endringer, kalles det en «pull» eller «fetch». Nå er det på tide å «pushe» den første commiten til GitHub. Dette gjør du slik:
git push -u origin master
Du vil bli bedt om å skrive inn brukernavn og passord for GitHub. Hvis du oppgir riktig informasjon, vil alt lastes opp, og du er klar.
Hvis du ønsker mer sikkerhet for dine GitHub-opplastinger, kan du bruke en SSH-nøkkel. Dette lar deg bruke et enkelt passord for SSH-nøkkelen for å laste opp, slik at du slipper å skrive inn hele GitHub-informasjonen hver gang. I tillegg kan bare de som har SSH-nøkkelen laste opp filendringer.
GitHub har detaljerte instruksjoner om hvordan du bruker SSH-nøkler. Du kan også lagre GitHub-informasjonen din på datamaskinen.
Det er alt! Når du ønsker å gjøre endringer i filene dine, kan du bruke disse tre korte kommandoene (etter at du har navigert til «MyNovel»-mappen):
git add .
Oversettelse: «Hei Git, klargjør for commit alle uregistrerte filer, samt nye endringer i filer du allerede sporer.»
git commit -m "1000 ord om den nye iPhone-anmeldelsen."
Oversettelse: «Hei Git, lagre disse endringene sammen med denne meldingen.»
git push origin master
Oversettelse: «Hei Git, last opp endringene til opprinnelsesversjonen av dette prosjektet på GitHub fra min hovedkopi på denne datamaskinen.»
Ekstra tips for Git og GitHub
Det er i bunn og grunn det hele, men her er noen ekstra tips for å gjøre opplevelsen din med Git og GitHub enda bedre:
Se tidligere commits
Du kan bruke GitHub for å se tidligere commits.
For å se tidligere commits, gå til MyNovel-depotet på GitHub. Øverst på hovedsiden, under «Kode»-fanen, ser du en seksjon som sier «[X] commits.»
Klikk på den, og du vil se en liste over alle dine commits. Klikk på den commiten du ønsker å se, og du vil se teksten din (forutsatt at du skrev den som ren tekst, ikke i Word). Alt som er uthevet med grønt er ny tekst som ble lagt til da commiten ble opprettet, og alt som er uthevet med rødt ble slettet.
Bruk Pull-kommandoen
Det er enkelt å hente et nytt depot på en annen maskin. Bare naviger til der du vil lagre repoen på den nye maskinen, for eksempel cd ~/Documents. Deretter skriver du:
git pull https://github.com/[Ditt GitHub brukernavn]/MyNovel.git
Skriv inn legitimasjonen din hvis du blir bedt om det, og i løpet av noen få sekunder er du klar. Nå kan du gjøre endringer og sende dem tilbake til GitHub via git push origin master. Når du kommer tilbake til datamaskinen der du vanligvis jobber, åpner du kommandolinjen, navigerer til prosjektmappen din og skriver git pull. De nye endringene vil lastes ned, og dermed er skriveprosjektet ditt oppdatert på tvers av alle enhetene dine.
Unngå konflikter
Som oftest er skriving en individuell aktivitet som kun involverer én person. Derfor presenterer denne artikkelen Git på en måte som kanskje ikke fungerer optimalt for et prosjekt med flere bidragsytere. Vi gjør for eksempel endringer direkte i hovedversjonen av romanen vår i stedet for å opprette det som kalles «grener». En gren er en «øvelsesversjon» av romanen der du kan gjøre endringer uten å påvirke originalversjonen. Det er som å ha to ulike kopier av romanen som eksisterer parallelt. Hvis du er fornøyd med endringene i praksisgrenen, kan du slå dem sammen til hovedversjonen (mastergrenen). Hvis ikke, kan du bare forkaste øvelsesgrenen.
Grener er et kraftig verktøy, og å bruke dem er den vanligste arbeidsflyten når flere forfattere samarbeider om ett prosjekt. Det er imidlertid ikke nødvendig for soloforfattere å bruke grener, så lenge du ikke gjør ulike endringer samtidig i mastergrenen på flere datamaskiner.
For eksempel bør du fullføre arbeidet ditt på skrivebordet, gjøre dine commits og deretter laste opp endringene til GitHub. Deretter går du til den bærbare datamaskinen din og «puller» ned alle de nye endringene før du gjør flere endringer. Hvis du ikke gjør dette, kan du oppleve det Git kaller «konflikter». Dette skjer når Git oppdager at det er endringer i GitHub og på datamaskinen din som ikke stemmer overens.
Det kan være vanskelig å løse en konflikt, så det er best å unngå det når det er mulig.
Når du begynner å bruke Git, er det masse du kan lære, som forgrening, forskjellen mellom «fetch» og «pull», hva GitHubs «pull requests» er, og hvordan du håndterer konflikter.
Git kan virke komplisert for nybegynnere, men når du først har fått taket på det, er det et kraftig verktøy du kan bruke for å administrere og lagre skrivearbeidet ditt.