Alternativa metoder för att hantera dina skrivprojekt
Det finns en mängd olika strategier för att organisera och lagra dina skrivprojekt. En del föredrar molntjänster som Dropbox eller onlinebaserade redigeringsverktyg som Google Dokument, medan andra lutar sig mot traditionella program som Microsoft Word. Personligen har jag valt att använda GitHub.
GitHub: Mer än bara kodhantering
Jag nyttjar Git och GitHub för att centralt lagra och få tillgång till alla mina alster. Git är ett oerhört effektivt verktyg för att spåra förändringar i dokument, och uppladdning till GitHub går blixtsnabbt. Dessutom är det lika snabbt och enkelt att ladda ner projektet till en annan enhet.
Om GitHub är ett nytt begrepp för dig, så är det en globalt populär plattform för lagring och underhåll av öppen källkod. Att använda det för att hantera sina texter kan tyckas oortodoxt, men det är det faktiskt inte! I grund och botten är ju kod inget annat än textrader, precis som dina artiklar, berättelser eller avhandlingar.
Runt 2013 initierade GitHub en rörelse för att skapa förvaringsplatser för alla typer av information, utöver kod. Trots att GitHub fortfarande är starkt förankrat i kodvärlden, väljer en del individer att använda det för att hantera sina texter och andra projekt som inte är kodrelaterade. Exempelvis använde en skribent Git och GitHub som grund för att skriva en manual, medan en annan författade en hel roman. En snabb sökning på internet avslöjar en mångfald av innovativa användningsområden för GitHub.
Vad är egentligen Git och GitHub?
Git är ett öppen källkodsprogram skapat av Linus Torvalds, som även ligger bakom Linux. Git följer upp förändringar i dokument och underlättar samarbete i realtid mellan flera personer som jobbar på samma text. Teknisk sett kallas det ett distribuerat system för versionshantering. Istället för att lagra versioner av dina dokument med jämna mellanrum, registrerar Git endast de ändringar du aktivt godkänner.
Dina dokument organiseras i ett arkiv, eller ”repo”, vilket helt enkelt är en sofistikerad term för din projektmapp. Din dokumentmapp på Windows skulle utgöra ett arkiv om du använde Git för att hantera det (vilket jag dock inte rekommenderar).
När du sparar förändringar i dina dokument med Git kallas det för en ”commit”. En commit är i praktiken en registrering av de senaste ändringarna du gjort i ett dokument. Varje commit får en lång unik identitetskod med siffror och bokstäver.
Om du öppnar en tidigare commit med dess ID, får du inte se hela projektet som i en historik i Word. Istället visas endast de senaste ändringarna som gjorts vid den specifika tidpunkten. Men det innebär inte att resten av projektet inte är sparat. Du kan ta bort all text från din projektmapp och ändå återskapa den senaste versionen genom att använda ett par kommandon i Git. Det är även möjligt att gå tillbaka och se hur projektet såg ut för en vecka eller till och med ett halvår sedan.
Dessutom kan du inkludera meddelanden till varje commit, vilket är mycket praktiskt. Till exempel, om du skriver något du känner dig osäker på, kan du spara en commit. Då finns avsnittet kvar i din historik även om du senare tar bort det från projektet.
Git fungerar bäst via kommandoraden, vilket kan vara en fördel men även en nackdel. Kommandoraden är utmärkt för att skapa commits och ladda upp förändringar. Däremot är den inte idealisk för att granska historiken.
Därför föredrar många att använda GitHub, en onlineplattform som ger ett webbaserat gränssnitt för dina Git-arkiv. På GitHub kan du enkelt se tidigare commits och dessutom ladda ner dina texter till valfri dator.
Med hjälp av Git och GitHub kan jag kontrollera min versionshistorik i detalj. Och jag har enkelt tillgång till mina texter på vilken dator som helst som har stöd för en Bash-kommandorad, vilket inkluderar maskiner med Windows, macOS, Linux och Chrome OS.
Oformaterade textfiler underlättar arbetet
Git kan hjälpa dig att skydda dina texter, men det gör dig inte till en bättre författare.
Git och GitHub kan i princip hantera alla typer av textfiler, men fungerar bäst med vanliga textfiler. Om du skriver i Microsoft Word fungerar det också, men du kan inte se dina tidigare commits i kommandoraden eller i GitHub. Istället måste du återställa en commit via kommandoraden (kallas ”checkout”) och sedan öppna din Word-fil. Då kommer Word-filen att se exakt likadan ut som vid tidpunkten för den commiten. Du kan sedan återgå till den nuvarande versionen med ett enkelt kommando.
Om du använder Scrivener så funkar det också. Scrivener lagrar filer som text, vilket innebär att tidigare commits också kan granskas i GitHub och via kommandoraden. Men Scrivener sparar också data som är viktigt för programmet, men inte för dig. Varje commit kommer att innehålla mycket ”skräp” som gör den svårläst.
Jag föredrar att använda vanliga textfiler, eftersom det är allt du behöver för att skriva, särskilt i de första utkastet.
Kom igång med Git
Låt oss dyka ner i de tekniska detaljerna om hur allt detta fungerar. Vi börjar med PC:n och fortsätter sedan till molnet med GitHub.
För att komma igång behöver du terminalprogrammet på macOS eller Linux. Om du använder Windows 10 måste du installera Ubuntu eller en annan Linux-distribution via Windows Subsystem for Linux (WSL), vilket är relativt enkelt. Du kan kolla in vår guide om hur man installerar Linux Bash-skalet på Windows 10. Alternativt kan du använda Cygwin om du har en äldre version av Windows.
Öppna terminalen och navigera till mappen du vill använda som ett Git-arkiv. För enkelhetens skull säger vi att vi har en mapp som heter ”MinRoman” i mappen Dokument. Notera att det inte finns något mellanslag i Git-arkivets namn. Det underlättar arbetet eftersom Bash har svårt att hantera mellanslag.
Navigera till mappen MinRoman i terminalen. För att göra det i Windows 10 använder du kommandot:
cd /mnt/c/Users/[DittAnvändarnamn]/Documents/MinRoman
Alla WSL-kommandon som interagerar med filer lagrade i Windows måste använda /mnt/. Observera även att lilla ”c” indikerar den enhet du använder. Om dina filer ligger på en ”D:/”-enhet använder du /d/.
För macOS och Linux är kommandot betydligt enklare:
cd ~/Documents/MinRoman
Från och med nu är kommandona identiska.
Nu måste vi initiera mappen MinRoman som ett Git-arkiv. Det här kommandot fungerar oavsett om du precis har påbörjat en ny roman eller om du redan har filer sparade.
git init
Din mapp är nu ett Git-arkiv. Om du inte tror mig kan du testa det här:
ls -a
Detta kommando ber datorn att visa allt i den aktuella mappen, inklusive dolda objekt. Du ska se något som heter ”.git” (notera punkten). Den dolda mappen ”.git” är platsen där din historik lagras. Du behöver aldrig öppna den, men den måste finnas där.
Din första commit
Innan vi gör vår första commit behöver Git ditt namn och e-postadress. Git använder denna information för att identifiera vem som har gjort en commit, och informationen inkluderas i loggen. I praktiken spelar detta ingen roll, eftersom skribenter ofta jobbar själva, men Git kräver informationen ändå.
För att ställa in din e-postadress och namn, använd följande kommandon:
git config --global user.email "[Din e-postadress]" git config --global user.name "[Ditt namn]"
Det är allt. Nu är det dags för första commit.
Anta att mappen ”MinRoman” innehåller tre dokument som heter: ”Kapitel1”, ”Kapitel2” och ”Kapitel3”. För att spara ändringar måste vi tala om för Git att övervaka dessa filer. För att göra det, skriv:
git add .
Punkten talar om för Git att övervaka alla ospårade filer i mappen (dvs. filer som du vill skapa historik för). Detta kommando ber även Git att förbereda alla spårade filer som har ändrats. Denna process kallas att ”iscensätta” filer inför en commit.
I det här exemplet är iscensättning inte så viktigt, men det kan vara användbart. Om du har gjort ändringar i kapitel 2 och 3, men bara vill commit:a ändringarna i kapitel 2, iscensätter du kapitel 2 så här:
git add Kapitel2.doc
Detta signalerar att du vill göra ändringarna i kapitel 2 redo för en commit, men inte de i kapitel 3.
Nu är det dags för första commit:
git commit -m "Detta är min första commit."
” -m ” är en flagga som talar om för Git att du vill göra en commit och lägga till ett meddelande, som du ser inom citattecknen. Jag brukar använda commit-meddelandena för att ange antalet ord. Jag skriver även in speciell information, som exempelvis: ”Denna commit innehåller en intervju med VD:n för Acme Widgets.”
Om jag skriver en berättelse kan meddelandet vara något i stil med: ”Denna commit innehåller den nya scenen där hunden springer iväg.” Tydliga meddelanden gör det enklare att hitta dina commits senare.
Nu när vi har börjat spåra våra dokument är det dags att placera våra texter i molnet med GitHub. Jag använder GitHub som en extra säkerhetskopia, en pålitlig plats för att se mina ändringar och ett sätt att få tillgång till mina texter på flera datorer.
Kom igång med GitHub
Du fyller i formuläret för att skapa ett nytt GitHub-arkiv.
Först måste du skapa ett kostnadsfritt konto på GitHub (du behöver inget betalkonto för att skapa privata arkiv). Du kan dock endast samarbeta med upp till tre personer i ett privat arkiv. Om du har ett team på fem personer eller fler som jobbar på en text måste du skaffa ett Pro-konto (kostar $7 per månad i skrivande stund).
När du har skapat ditt konto, skapar vi ett nytt arkiv. Logga in och gå till https://github.com/new.
Det första vi behöver göra är att ge arkivet ett namn. Du kan använda samma namn som du gav mappen på din PC. Under ”Repository Name” skriver du ”MinRoman”.
”Beskrivningen” är valfri, men jag gillar att använda den. Du kan skriva något som ”Min fantastiska nya roman om en pojke, en flicka och deras hund”, osv.
Välj sedan alternativknappen ”Privat”, men markera inte rutan som heter ”Initiera detta arkiv med en README”. Vi vill inte göra det, eftersom vi redan har ett arkiv på vår PC. Om vi skapar en README-fil nu blir det mer komplicerat.
Klicka sedan på ”Skapa arkiv”. Kopiera URL:en under ”Snabb installation – om du har gjort det här förut”. Den ska se ut ungefär så här:
https://github.com/[Ditt GitHub Användarnamn]/MinRoman.git
Nu går vi tillbaka till vår älskade kommandorad.
Skicka ditt arkiv från datorn till molnet
Använda Git på kommandoraden.
Första gången du ansluter ett arkiv till GitHub måste du använda några speciella kommandon. Det första är:
git remote add origin https://github.com/[Ditt GitHub Användarnamn]/MinRoman.git
Detta talar om för Git att ett fjärrlager är ursprunget för ”MinRoman”. URL:en kopplar sedan Git till fjärrursprunget. Oroa dig inte så mycket över termen ”ursprung”, det är bara en konvention. Du kan kalla det ”fluffigt” om du vill – ursprung är bara enklare eftersom det är det vanligaste sättet att använda Git.
När du laddar upp nya ändringar med Git kallas det ”push”. När du laddar ner ändringar kallas det ”pull” eller ”fetch”. Nu är det dags att göra din första push till GitHub. Gör så här:
git push -u origin master
Du kommer att bli ombedd att ange ditt GitHub-användarnamn och lösenord. Om du skriver in dina uppgifter korrekt laddas allt upp och du är igång.
Om du vill öka säkerheten för dina GitHub-uppladdningar kan du använda en SSH-nyckel. Då behöver du bara ange lösenordet för SSH-nyckeln för att ladda upp, istället för dina fullständiga GitHub-uppgifter varje gång. Dessutom kan endast någon med SSH-nyckeln ladda upp filändringar.
Om du vill veta mer om SSH-nycklar, har GitHub utförliga instruktioner om hur man använder dem. Du kan också spara dina Git-uppgifter på din PC.
Det är allt! Nu kan du göra ändringar i dina filer med hjälp av dessa tre kommandon (efter att du navigerat till mappen ”MinRoman”):
git add .
Översättning: ”Hej Git, iscensätt för commit alla ospårade filer, samt ändringar i filer som du redan övervakar.”
git commit -m "1000 ord i den nya recensionen av iPhonen."
Översättning: ”Hej Git, spara dessa ändringar tillsammans med det här meddelandet.”
git push origin master
Översättning: ”Hej Git, ladda upp ändringarna till ursprungsversionen av detta projekt på GitHub från min huvudkopia på den här datorn.”
Git och GitHub: Bonustips
Det är i stort sett det hela, men här kommer några extra tips som kan förbättra din upplevelse med Git och GitHub:
Granska tidigare commits
Du kan använda GitHub för att se tidigare commits.
För att granska tidigare commits går du till ditt MinRoman-arkiv på GitHub. Högst upp på huvudsidan, under fliken ”Kod” finns en sektion som säger ”[X] commits”.
Klicka på den och du kommer se en lista över alla dina commits. Klicka på den commit du är intresserad av, så ser du texten (om du har skrivit i en vanlig textfil och inte i Word). Allt som är markerat i grönt är ny text som har lagts till i samband med commiten. Allt i rött har tagits bort.
Använd pull-kommandot
Det är enkelt att kopiera ett arkiv till en annan dator. Navigera till den plats där du vill spara arkivet på den nya datorn, till exempel cd ~/Documents. Skriv sedan:
git pull https://github.com/[Ditt GitHub Användarnamn]/MinRoman.git
Skriv in dina uppgifter om du blir uppmanad, så är du redo att sätta igång på några sekunder. Gör nya ändringar och skicka tillbaka dem till GitHub via git push origin master. När du återgår till datorn där du brukar jobba, öppnar du kommandoraden, går till din projektmapp och skriver git pull. Då kommer de nya ändringarna att laddas ner och ditt projekt är uppdaterat på alla dina enheter.
Undvik korsande strömmar
Oftast är skribenter soloartister. Därför använder vi Git i den här artikeln på ett sätt som inte skulle fungera för ett projekt med flera medarbetare. Vi gör ändringar direkt i huvudversionen av vår roman, istället för att skapa så kallade ”grenar”. En gren är en testversion av romanen, där du kan göra ändringar utan att påverka originalet. Det är som att ha två kopior av din roman som existerar parallellt, utan att påverka varandra. Om du gillar ändringarna i testgrenen kan du slå ihop dem med masterversionen (eller mastergrenen). Om du inte gillar dem kan du bara slänga testgrenen.
Grenar är ett kraftfullt verktyg och det vore den normala arbetsgången med flera skribenter i ett projekt. Soloskribenter behöver enligt mig inte använda grenar, så länge du inte gör flera ändringar i mastergrenen samtidigt på olika datorer.
Till exempel bör du avsluta ditt arbete på din stationära dator, göra dina commits och sedan skicka dina ändringar till GitHub. Sedan går du till din bärbara dator och laddar ner alla nya ändringar innan du gör några fler ändringar. Om du inte gör det kan du hamna i vad Git kallar ”konflikter”. Det är när Git säger: ”Hej, det finns ändringar i GitHub och på den här datorn som inte stämmer överens. Hjälp mig att lösa detta.”
Att reda ut en konflikt kan vara krångligt, så det är bäst att undvika det om möjligt.
När du väl kommit igång med Git finns det mycket mer att lära sig, som grenar, skillnaden mellan fetch och pull, vad en GitHub pull-request är och hur man hanterar den fruktade konflikten.
Git kan verka komplicerat för nybörjare, men när du väl fått kläm på det är det ett kraftfullt verktyg för att hantera och lagra dina texter.