Hur författare kan använda GitHub för att lagra sitt arbete

Det finns många sätt du kan hantera och lagra dina skrivprojekt. Vissa människor föredrar molnlagringstjänster (som Dropbox) eller onlineredigerare (som Google Docs), medan andra använder skrivbordsprogram (som Microsoft Word). Jag använder något som heter GitHub.

GitHub: Det är för mer än bara kod

Jag använder Git och GitHub för att lagra och komma åt allt jag skriver. Git är ett effektivt verktyg som du kan använda för att spåra dokumentändringar, plus att du kan ladda upp till GitHub supersnabbt. Det är också snabbt och enkelt att ladda ner ditt arbete till en andra eller tredje enhet.

Om du aldrig har hört talas om GitHub är det världens mest populära destination för att lagra och underhålla öppen källkod. Det kan låta som en galen plats att vara värd för ditt skrivande, men det är det inte! När allt kommer omkring är kod bara rader och rader med text, som din artikel, berättelse eller avhandling.

Runt 2013, GitHub började uppmuntra människor att skapa arkiv för all slags information, inte bara kod. GitHub lämnade aldrig riktigt sina kodningsrötter, men vissa människor använder den fortfarande för att lagra skrivning och andra icke-kodande projekt. Till exempel använde en person Git och GitHub för att skriva en instruktionsbok, medan en annan skrev en roman. Leta runt på Google, och du hittar alla typer av galna användningsområden för GitHub.

Vad är Git och GitHub?

Informationsdelen av ett GitHub-förråd.

Git är ett program med öppen källkod skapat av Linus Torvalds, av Linux berömmelse. Git spårar ändringar i dokument och gör det lättare för flera personer att arbeta med samma dokument på distans. I tekniskt tal kallas det ett distribuerat versionskontrollsystem (eller distribuerad VCS). Git sparar inte godtyckligt versioner av dina dokument med bestämda intervall. Istället lagrar den ändringar i dina dokument endast när du säger till det.

Dina dokument bildar ett arkiv (eller repo), vilket bara är en fancy term för din projektmapp. Din dokumentmapp i Windows, till exempel, skulle vara ett arkiv om du använde Git för att hantera den (men gör inte det).

När du lagrar ändringar i dina dokument i Git kallas det en ”commit”. En commit är bara en registrering av de senaste ändringarna du gjort i ett dokument. Varje commit tilldelas en lång sträng med siffror och bokstäver som dess ID.

Om du ringer upp en tidigare commit med dess ID, ser du inte hela projektet som du gör i Words dokumenthistorik. Du ser bara de senaste ändringarna när commit gjordes. Detta betyder dock inte att hela projektet inte spelades in. Du kan ta bort allt du skriver från en projektmapp och fortfarande få tillbaka den senaste versionen med några git-kommandon. Du kan till och med gå tillbaka och se hur projektet såg ut för en vecka sedan, eller för sex månader sedan.

Du kan också inkludera meddelanden till varje commit, vilket är mycket användbart. Till exempel, om du skriver något men inte är säker på att du vill behålla det, gör bara en commit. Avsnittet finns sedan kvar i din commit-historik även om du tar bort det från projektet senare.

Git fungerar bäst på kommandoraden, vilket är en stor fördel men också har sina nackdelar. Kommandoraden är bra för att skapa commits och ladda upp ändringar. Men om du vill se en commit-historik är det inte idealiskt.

Det är därför många människor gillar GitHub — en populär onlinetjänst som erbjuder ett webbgränssnitt för dina Git-förråd. På GitHub kan du enkelt se tidigare åtaganden, samt ladda ner ditt skrivande till flera datorer.

Tillsammans låter Git och GitHub mig kontrollera min versionshistorik på en detaljerad nivå. Och det är lätt att få mitt skrivande på vilken dator som helst som kan köra en Bash-kommandorad som nuförtiden inkluderar Windows-, Mac-, Linux- och Chrome OS-maskiner.

Oformaterade textfiler gör saker enkelt

Git kan hjälpa till att rädda ditt skrivande, men det kan inte göra dig till en bättre författare.

Git och GitHub förbinder sig i stort sett alla filtyper för att skriva, även om det fungerar bäst med vanlig text. Om du skriver i Microsoft Word kommer det att fungera, men du kommer inte att kunna se dina tidigare commits på kommandoraden eller i GitHub. Istället måste du anropa en tidigare commit på kommandoraden (kallad ”checkout”) och sedan öppna din Word-fil. Word-filen ser sedan ut precis som den gjorde när du gjorde den ursprungliga commit, och du kan återgå till din nuvarande version med ett annat snabbt kommando.

Om du använder Scrivener, det fungerar också. Scrivener sparar filer som text, så det visar också tidigare bekräftelser på GitHub och kommandoraden. Men Scrivener sparar också data som är viktig för programmet, men inte för dig. I varje commit kommer du att få mycket skräp som gör det svårt att läsa.

Jag använder vanliga textfiler eftersom det är allt du behöver för att sätta ihop ord, särskilt i dina första utkast.

Komma igång med Git

Låt oss gå in på de tekniska detaljerna om hur allt detta fungerar. Vi börjar med PC och flyttar sedan upp till molnet med GitHub.

För att komma igång behöver du terminalprogrammet på macOS eller Linux. Om din dator kör Windows 10 måste du installera Ubuntu eller en annan Linux-distribution via Windows Subsystem for Linux (WSL), vilket är ganska enkelt. Du kan kolla in vår handledning om hur du installerar Linux Bash-skalet på Windows 10. Eller, om du använder en äldre version av Windows, kan du använda Cygwin för att få ett Bash-skal.

Öppna din terminal och navigera till mappen du vill använda som ett Git-förråd. För våra syften, låt oss säga att vi har en mapp som heter ”MyNovel” i mappen Dokument. Observera att det inte finns något mellanslag mellan orden i vår Git-repo. Du kommer att göra ditt liv enklare om du gör det på det här sättet eftersom Bash inte gillar utrymmen och det blir förvirrande att hantera dem.

Navigera sedan till mappen MyNovel i terminalen. För att göra detta i Windows 10 är kommandot:

cd /mnt/c/Users/[YourUserName]/Documents/MyNovel

Alla WSL-kommandon som interagerar med filer som sparats i Windows måste använda /mnt/. Observera också att gemener ”c” indikerar den enhet du är på. Om dina filer finns på en ”D:/”-enhet, använder du /d/.

För macOS och Linux är kommandot mycket enklare:

cd ~/Documents/MyNovel

Härifrån är kommandona desamma.

Nu måste vi initiera MyNovel-mappen som ett Git-förråd. Det här kommandot fungerar oavsett om du precis har startat en ny roman eller redan har några sparade filer inuti.

git init

Din mapp är nu ett Git-förråd. Tro mig inte? Skriv in detta:

ls -a

Det kommandot ber datorn att lista allt i den aktuella mappen, inklusive dolda objekt. Du bör se något listat längst upp som heter ”.git” (notera punkten). Den dolda ”.git”-mappen är där din dokumentversionshistorik sparas. Du ska aldrig behöva öppna det här, men det måste finnas där.

Det första åtagandet

Innan vi gör vårt första åtagande vill Git veta ditt namn och din e-postadress. Git använder denna information för att identifiera vem som gjorde commit, och den informationen ingår i commit-loggen. För praktiska ändamål spelar detta ingen roll eftersom författare vanligtvis flyger solo, men Git kräver det fortfarande.

Gör följande för att ställa in din e-postadress och adress:

git config --global user.email "[Your email]"

git config --global user.name "[Your name]"

Det är allt. Nu till den första commit.

Låt oss anta att det finns tre dokument i mappen ”MyNovel” som heter: ”Chapter1”, ”Chapter2” och ”Chapter3.” För att spara ändringar måste vi berätta för Git att spåra dessa filer. För att göra detta, skriv:

git add .

Perioden säger åt Git att övervaka alla ospårade filer i mappen (dvs. filer som du vill skapa historik för). Detta kommando säger också åt Git att förbereda alla spårade filer som har ändrats. Denna process kallas iscensättningsfiler för commit.

För våra syften är iscensättning inte så viktigt, men det kan vara användbart. Om du gör ändringar i kapitel 2 och kapitel 3, men bara vill genomföra ändringarna i kapitel 2, skulle du stega kapitel 2 så här:

git add Chapter2.doc

Detta talar om för Git att du vill få ändringarna i kapitel 2 redo för commit, men inte kapitel 3.

Nu är det dags för första commit:

Git commit -m "This is my first commit."

”-m” kallas en flagga, och den talar om för Git att du vill göra en commit och slå på ett meddelande, som du ser mellan citattecken. Jag gillar att använda mina commit-meddelanden för att markera antalet ord. Jag använder dem också för att notera speciell information, såsom: ”Detta åtagande inkluderar en intervju med VD:n för Acme Widgets.”

Om jag skriver en berättelse, kan jag inkludera ett meddelande som säger: ”Det här engagemanget har den nya scenen där hunden springer iväg.” Användbara meddelanden gör det lättare att hitta dina åtaganden senare.

Nu när vi har börjat spåra våra dokument är det dags att lägga vårt skrivande i molnet med GitHub. Jag använder GitHub som en extra säkerhetskopia, en pålitlig plats att titta på mina dokumentändringar och ett sätt att komma åt mina saker på flera datorer.

Komma igång med GitHub

Du fyller i formuläret för att skapa ett nytt GitHub-förråd.

Först måste du registrera dig för ett gratis konto på GitHub (du behöver inget betalkonto för att skapa privata arkiv). Du kan dock bara samarbeta med upp till tre personer på en privat repo. Om du har ett team på fem eller fler som arbetar med en artikel måste du registrera dig för ett Pro-konto ($7 per månad, när detta skrivs).

När du har skapat ditt konto, låt oss göra en ny repo. Logga in på ditt konto och gå till https://github.com/new.

Det första vi behöver göra är att namnge förvaret. Du kan använda samma namn som du använde för mappen på din PC. Under ”Repository Name”, skriv ”MyNovel.”

”Beskrivningen” är valfri, men jag gillar att använda den. Du kan skriva något som ”Min fantastiska nya roman om en pojke, en tjej och deras hund” osv.

Välj sedan alternativknappen ”Privat”, men markera inte rutan som heter ”Initiera detta förråd 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 just nu gör det det svårare.

Klicka sedan på ”Skapa arkiv.” Kopiera URL:en under ”Snabb installation – om du har gjort det här förut”. Det borde se ut ungefär så här:

https://github.com/[Your GitHub User Name]/MyNovel.git

Nu är det tillbaka till skrivbordet och vår älskade kommandorad.

Skicka ditt skrivbordsarkiv till molnet

Använder Git på kommandoraden.

Första gången du ansluter ett repo till GitHub måste du använda några specialiserade kommandon. Den första är:

git remote add origin https://github.com/[Your GitHub User Name]/MyNovel.git

Detta berättar för Git att ett fjärrlager är ursprunget till ”MyNovel.” URL:en pekar sedan Git mot det avlägsna ursprunget. Häng dig inte för mycket på termen ”ursprung;” det är bara en konvention. Du kan kalla det ”fluffigt” om du vill – ursprunget ä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 en ”push”. När du laddar ner ändringar kallas det ”pull” eller ”hämta”. Nu är det dags att göra ditt första åtagande till GitHub. Så här gör du:

git push -u origin master

Du kommer att bli ombedd att ange ditt GitHub-användarnamn och lösenord. Om du skriver in dina referenser korrekt laddas allt upp och du är igång.

Om du vill ha mer säkerhet för dina GitHub-uppladdningar kan du använda en SSH-nyckel. Detta gör att du kan använda ett enda lösenord för SSH-nyckeln att ladda upp, så att du inte behöver skriva in dina fullständiga GitHub-uppgifter varje gång. Dessutom kan bara någon med SSH-nyckeln ladda upp filändringar.

Om du vill ha mer information om SSH-nycklar, GitHub har fullständiga instruktioner om hur man använder dem. Du kan också spara dina Git-uppgifter på din PC.

Det är allt! Nu, när du vill göra ändringar i dina filer, kan du göra det med dessa tre korta kommandon (efter att du har navigerat till mappen ”MyNovel”):

git add .

Översättning: ”Hej, Git-stadiet för commit alla ospårade filer, såväl som nya ändringar av filer du redan spårar.”

git commit -m "1,000 words on the new iPhone review."

Ö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 ganska mycket det, men här är några extra tips för att göra din upplevelse med Git och GitHub ännu bättre:

Visa tidigare åtaganden

Du kan använda GitHub för att se tidigare åtaganden.

För att se tidigare åtaganden, gå till ditt MyNovel-förråd på GitHub. Längst upp på huvudsidan, under fliken ”Kod”, ser du ett avsnitt som säger ”[X] begår.”

Klicka på den så ser du en lista över alla dina åtaganden. Klicka på den commit du vill ha så ser du din text (om du skrev den i vanlig text och inte i Word, alltså). Allt markerat i grönt var ny text när commit skapades; allt i rött raderades.

Använd kommandot Pull

Det är lätt att ta ett nytt arkiv på en annan maskin. Navigera bara till var du vill spara repet på den nya maskinen, till exempel cd ~/Documents. Skriv sedan:

git pull https://github.com/[Your GitHub User Name]/MyNovel.git

Skriv in dina referenser, om du uppmanas, och inom några sekunder är du redo att gå. Gör nu nya ändringar och skicka dem sedan tillbaka till GitHub via git push origin master. När du kommer tillbaka till datorn där du brukar arbeta, öppna bara kommandoraden, navigera till din projektmapp och skriv in git pull. De nya ändringarna kommer att laddas ner, och precis som att ditt skrivprojekt är uppdaterat på alla dina enheter.

Korsa inte strömmar

För det mesta är skrivandet inte en laginsats och involverar bara en person. På grund av det använder den här artikeln Git på ett sätt som inte skulle fungera för ett projekt med flera personer. Specifikt gjorde vi redigeringar direkt i huvudversionen av vår roman istället för att skapa vad som kallas ”grenar”. En gren är en övningsversion av romanen där du kan göra ändringar utan att påverka den ursprungliga mastern. Det är som att ha två olika kopior av din roman som existerar parallellt utan att någon av dem påverkar den andra. Om du gillar ändringarna i övningsgrenen kan du slå ihop dem i masterversionen (eller mastergrenen). Om du inte vill göra det går det också bra. Släng bara övningsgrenen.

Filialer är mycket kraftfulla, och att använda dem skulle vara det primära arbetsflödet med flera skribenter på ett enda projekt. Soloförfattare behöver egentligen inte använda grenar, enligt min mening – så länge du inte gör olika ändringar i mastergrenen samtidigt på flera datorer.

Till exempel bör du slutföra ditt arbete på skrivbordet, göra dina commits och sedan skicka ändringarna till GitHub. Gå sedan till din bärbara dator och dra ner alla nya ändringar innan du gör några ytterligare ändringar. Om du inte gör det kan du sluta med vad Git kallar ”konflikter.” Det är då Git säger, ”Hej, det finns förändringar i GitHub och på den här datorn som inte matchar. Hjälp mig ta reda på det här.”

Att sortera sig ur en konflikt kan vara jobbigt, så det är bäst att undvika det när det är möjligt.

När du väl kommit igång med Git, finns det massor av saker du kan lära dig, som förgrening, skillnaden mellan en apport och en pull, vad GitHubs pull-förfrågningar är och hur man hanterar den fruktade konflikten.

Git kan verka komplicerat för nykomlingar, men när du väl fått kläm på det är det ett kraftfullt verktyg du kan använda för att hantera och lagra ditt skrivande.