Det er mange måter du kan administrere og lagre skriveprosjektene dine på. Noen mennesker foretrekker skylagringstjenester (som Dropbox) eller nettredaktører (som Google Docs), mens andre bruker skrivebordsapplikasjoner (som Microsoft Word). Jeg bruker noe som heter GitHub.
Innholdsfortegnelse
GitHub: Det er for mer enn bare kode
Jeg bruker Git og GitHub for å lagre og få tilgang til alt jeg skriver. Git er et effektivt verktøy du kan bruke til å spore dokumentendringer, pluss at du kan laste opp til GitHub superraskt. Det er også raskt og enkelt å laste ned arbeidet ditt til en andre eller tredje enhet.
Hvis du aldri har hørt om GitHub, er det verdens mest populære reisemål for å lagre og vedlikeholde åpen kildekode. Det høres kanskje ut som et sprøtt sted å være vert for skrivingen din, men det er det ikke! Tross alt er kode bare linjer og linjer med tekst, som artikkelen din, historien eller avhandlingen din.
Rundt 2013, GitHub begynte å oppmuntre folk til å lage repositories for all slags informasjon, ikke bare kode. GitHub har egentlig aldri forlatt kodingsrøtter, men noen bruker den fortsatt til å lagre skriving og andre ikke-kodende prosjekter. For eksempel brukte en person Git og GitHub for å skrive en instruksjonsbokmens en annen skrev en roman. Let rundt på Google, og du finner alle slags sprø bruksområder for GitHub.
Hva er Git og GitHub?
Informasjonsdelen av et GitHub-depot.
Git er et åpen kildekode-program laget av Linus Torvalds, av Linux-berømmelse. Git sporer endringer i dokumenter og gjør det enklere for flere personer å arbeide med det samme dokumentet eksternt. I tech-speak kalles det et distribuert versjonskontrollsystem (eller distribuert VCS). Git lagrer ikke vilkårlig versjoner av dokumentene dine med angitte intervaller. I stedet lagrer den endringer i dokumentene dine bare når du ber den om det.
Dokumentene dine danner et depot (eller repo), som bare er en fancy betegnelse for prosjektmappen din. Dokumentmappen din i Windows, for eksempel, ville være et depot hvis du brukte Git til å administrere den (men ikke gjør det).
Når du lagrer endringer i dokumentene dine i Git, kalles det en «commit». En forpliktelse er bare en oversikt over de siste endringene du har gjort i et dokument. Hver commit er tildelt en lang rekke tall og bokstaver som ID.
Hvis du kaller opp en tidligere forpliktelse ved hjelp av ID-en, ser du ikke hele prosjektet slik du gjør i Words dokumenthistorikk. Du ser bare de siste endringene når forpliktelsen ble gjort. Dette betyr imidlertid ikke at hele prosjektet ikke ble spilt inn. Du kan slette alt du skriver fra en prosjektmappe og fortsatt få den nyeste versjonen tilbake med noen få git-kommandoer. Du kan til og med gå tilbake og se hvordan prosjektet så ut for en uke siden, eller for seks måneder siden.
Du kan også inkludere meldinger til hver commit, noe som er veldig nyttig. For eksempel, hvis du skriver noe, men ikke er sikker på at du vil beholde det, er det bare å forplikte seg. Seksjonen overlever deretter i forpliktelsesloggen din selv om du sletter den fra prosjektet senere.
Git fungerer best på kommandolinjen, noe som er en stor fordel, men også har sine ulemper. Kommandolinjen er fin for å opprette forpliktelser og laste opp endringer. Imidlertid, hvis du vil se en forpliktelseshistorie, er det ikke ideelt.
Dette er grunnen til at mange liker GitHub – en populær nettjeneste som tilbyr et nettgrensesnitt for Git-lagrene dine. På GitHub kan du enkelt se tidligere forpliktelser, samt laste ned skrivingene dine til flere PC-er.
Sammen lar Git og GitHub meg kontrollere versjonshistorikken min på et detaljert nivå. Og det er lett å skrive på en hvilken som helst PC som kan kjøre en Bash-kommandolinje som i disse dager inkluderer Windows-, Mac-, Linux- og Chrome OS-maskiner.
Vanlige tekstfiler gjør ting enkelt
Git kan hjelpe med å redde skrivingen din, men det kan ikke gjøre deg til en bedre forfatter.
Git og GitHub forplikter seg til stort sett alle filtyper for skriving, selv om det fungerer best med ren tekst. Hvis du skriver i Microsoft Word, vil det fungere, men du vil ikke kunne se dine tidligere forpliktelser på kommandolinjen eller i GitHub. I stedet må du kalle opp en tidligere forpliktelse på kommandolinjen (kalt en «kasse») og deretter åpne Word-filen. Word-filen ser da ut akkurat som den gjorde da du foretok den opprinnelige commit, og du kan gå tilbake til gjeldende versjon med en annen rask kommando.
Hvis du bruker Scrivener, det fungerer også. Scrivener lagrer filer som tekst, så den viser også tidligere forpliktelser på GitHub og kommandolinjen. Men Scrivener lagrer også data som er viktige for programmet, men ikke for deg. I hver commit vil du ende opp med mye søppel som gjør det vanskelig å lese.
Jeg bruker vanlige tekstfiler fordi det er alt du trenger for å sette sammen ord, spesielt i de første utkastene dine.
Komme i gang med Git
La oss gå inn på de tekniske detaljene om hvordan alt dette fungerer. Vi starter med PC, og går deretter opp til skyen med GitHub.
For å komme i gang trenger du terminalprogrammet på macOS eller Linux. Hvis datamaskinen din kjører 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 vår veiledning om hvordan du installerer Linux Bash-skallet på Windows 10. Eller, hvis du bruker en eldre versjon av Windows, kan du bruke Cygwin for å få et Bash-skall.
Åpne terminalen din og naviger til mappen du vil bruke som et Git-depot. For våre formål, la oss si at vi har en mappe kalt «MyNovel» i Dokumenter-mappen. Merk at det ikke er mellomrom mellom ordene i Git-repoen vår. Du vil gjøre livet ditt enklere hvis du gjør det på denne måten, da Bash ikke liker mellomrom, og det blir forvirrende å håndtere dem.
Deretter navigerer du til MyNovel-mappen i terminalen. For å gjøre dette i Windows 10 er kommandoen:
cd /mnt/c/Users/[YourUserName]/Documents/MyNovel
Enhver WSL-kommando som samhandler med filer som er lagret i Windows må bruke /mnt/. Vær også oppmerksom på at den små bokstaven «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
Herfra er kommandoene de samme.
Nå må vi initialisere MyNovel-mappen som et Git-depot. Denne kommandoen fungerer enten du akkurat har startet en ny roman eller allerede har noen lagrede filer inne.
git init
Mappen din er nå et Git-depot. Tro meg ikke? Skriv inn dette:
ls -a
Den kommandoen ber datamaskinen om å liste opp alt i gjeldende mappe, inkludert skjulte elementer. Du bør se noe oppført øverst kalt «.git» (merk punktum). Den skjulte «.git»-mappen er der dokumentets versjonshistorikk lagres. Du burde aldri trenge å åpne dette, men det må være der.
Den første forpliktelsen
Før vi gjør vår første forpliktelse, ønsker Git å vite navnet ditt og e-postadressen din. Git bruker denne informasjonen til å identifisere hvem som foretok forpliktelsen, og den informasjonen er inkludert i forpliktelsesloggen. For praktiske formål spiller dette ingen rolle siden forfattere vanligvis flyr solo, men Git krever det fortsatt.
Gjør følgende for å angi e-post og adresse:
git config --global user.email "[Your email]" git config --global user.name "[Your name]"
Det er det. Nå over til den første forpliktelsen.
La oss anta at det er tre dokumenter i «MyNovel»-mappen kalt: «Chapter1», «Chapter2» og «Chapter3.» For å lagre endringer, må vi fortelle Git å spore disse filene. For å gjøre dette, skriv:
git add .
Perioden forteller Git å overvåke alle usporede filer i mappen (dvs. filer du vil lage historier for). Denne kommandoen forteller også Git å forberede eventuelle sporede filer som har blitt endret. Denne prosessen kalles iscenesettelse av filer for commit.
For våre formål er iscenesettelse ikke så viktig, men det kan være nyttig. Hvis du gjør endringer i kapittel 2 og kapittel 3, men bare ønsker å forplikte deg til endringene i kapittel 2, vil du iscenesette kapittel 2 slik:
git add Chapter2.doc
Dette forteller Git at du ønsker å gjøre endringene i kapittel 2 klare for commit, men ikke kapittel 3.
Nå er det tid for den første forpliktelsen:
Git commit -m "This is my first commit."
«-m» kalles et flagg, og det forteller Git at du vil forplikte deg og slå på en melding, som du ser mellom anførselstegnene. Jeg liker å bruke forpliktelsesmeldingene mine til å markere antall ord. Jeg bruker dem også til å legge merke til spesiell informasjon, for eksempel: «Denne forpliktelsen inkluderer et intervju med administrerende direktør for Acme Widgets.»
Hvis jeg skriver en historie, kan jeg inkludere en melding som sier: «Denne forpliktelsen har den nye scenen der hunden løper.» Nyttige meldinger gjør det lettere å finne forpliktelsene dine senere.
Nå som vi har begynt å spore dokumentene våre, er det på tide å legge teksten vår i skyen med GitHub. Jeg bruker GitHub som en ekstra sikkerhetskopi, et pålitelig sted å se på dokumentendringene mine, og en måte å få tilgang til tingene mine på flere PC-er.
Komme i gang med GitHub
Du fyller ut skjemaet for å opprette et nytt GitHub-depot.
Først må du registrere deg for en gratis konto på GitHub (du trenger ikke en betalt konto for å opprette private arkiver). Du kan imidlertid bare samarbeide med opptil tre personer på en privat repo. Hvis du har et team på fem eller flere som jobber med en artikkel, må du registrere deg for en Pro-konto ($7 per måned, når dette skrives).
Etter at du har opprettet kontoen din, la oss lage en ny repo. Logg på kontoen din og gå til https://github.com/new.
Det første vi må gjøre er å gi navn til depotet. Du kan bruke samme navn som du brukte for mappen på din PC. 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 merk av i boksen som heter «Initialiser dette depotet med en README.» Vi ønsker ikke å gjøre det, fordi vi allerede har et depot på PC-en vår. Hvis vi lager en README-fil akkurat nå, gjør det ting vanskeligere.
Klikk deretter på «Opprett arkiv.» Kopier URL-en under «Rask oppsett—hvis du har gjort denne typen ting før». Det skal se omtrent slik ut:
https://github.com/[Your GitHub User Name]/MyNovel.git
Nå er det tilbake til skrivebordet og vår elskede kommandolinje.
Push Desktop Repository til skyen
Bruke Git på kommandolinjen.
Første gang du kobler en repo til GitHub, må du bruke noen få spesialiserte kommandoer. Den første er:
git remote add origin https://github.com/[Your GitHub User Name]/MyNovel.git
Dette forteller Git at et eksternt depot er opphavet til «MyNovel.» URL-en peker deretter Git mot den eksterne opprinnelsen. Ikke heng deg for mye opp i begrepet «opprinnelse»; det er bare en konvensjon. Du kan kalle det «fluffy» hvis 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 å presse din første forpliktelse til GitHub. Her er hva du gjør:
git push -u origin master
Du blir bedt om å skrive inn GitHub brukernavn og passord. Hvis du skriver inn legitimasjonen din riktig, lastes alt opp, og du er i gang.
Hvis du vil ha mer sikkerhet for GitHub-opplastingene dine, kan du bruke en SSH-nøkkel. Dette lar deg bruke et enkelt passord for SSH-nøkkelen for å laste opp, slik at du ikke trenger å skrive inn hele GitHub-legitimasjonen hver gang. I tillegg kan bare noen med SSH-nøkkelen laste opp filendringer.
Hvis du vil ha mer informasjon om SSH-nøkler, GitHub har fulle instruksjoner om hvordan du bruker dem. Du kan også lagre Git-legitimasjonen din på PC-en din.
Det er det! Nå, når du vil foreta endringer i filene dine, kan du gjøre det med disse tre korte kommandoene (etter at du har navigeret til «MyNovel»-mappen):
git add .
Oversettelse: «Hei, Git-stadiet for commit alle usporede filer, så vel som nye endringer i filer du allerede sporer.»
git commit -m "1,000 words on the new iPhone review."
Oversettelse: «Hei Git, lagre disse endringene ved siden av denne meldingen.»
git push origin master
Oversettelse: «Hei Git, last opp endringene til opprinnelsesversjonen av dette prosjektet på GitHub fra min hovedkopi på denne PCen.»
Git og GitHub bonustips
Det er stort sett det, men her er noen ekstra tips for å gjøre opplevelsen din med Git og GitHub enda bedre:
Se tidligere forpliktelser
Du kan bruke GitHub for å se tidligere forpliktelser.
For å se tidligere forpliktelser, gå til MyNovel-depotet på GitHub. Mot toppen av hovedsiden, under «Kode «-fanen, ser du en seksjon som sier «[X] forplikter seg.»
Klikk på den, og du ser en liste over alle forpliktelsene dine. Klikk på commit du ønsker, og du ser teksten din (hvis du skrev den i ren tekst og ikke Word, altså). Alt uthevet i grønt var ny tekst da commit ble opprettet; alt i 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/[Your GitHub User Name]/MyNovel.git
Skriv inn legitimasjonen din, hvis du blir bedt om det, og om noen sekunder er du klar til å gå. Nå, foreta nye endringer, og send dem deretter tilbake til GitHub via git push origin master. Når du kommer tilbake til PC-en der du vanligvis jobber, åpner du bare kommandolinjen, navigerer til prosjektmappen din og skriver inn git pull. De nye endringene vil lastes ned, og akkurat som det er skriveprosjektet ditt oppdatert på tvers av enhetene dine.
Ikke kryss bekker
Mesteparten av tiden er skriving ikke en laginnsats og involverer bare én person. På grunn av det bruker denne artikkelen Git på en måte som ikke ville fungere for et prosjekt med flere personer. Nærmere bestemt gjorde vi redigeringer direkte til hovedversjonen av romanen vår i stedet for å lage det som kalles «grener». En gren er en praksisversjon av romanen der du kan gjøre endringer uten å påvirke den originale masteren. Det er som å ha to forskjellige kopier av romanen din som eksisterer parallelt uten at noen av dem påvirker den andre. Hvis du liker endringene i praksisgrenen, kan du slå dem sammen til masterversjonen (eller mastergrenen). Hvis du ikke vil gjøre det, er det også greit. Bare kast øvingsgrenen.
Grener er veldig kraftige, og å bruke dem vil være den primære arbeidsflyten med flere forfattere på et enkelt prosjekt. Soloforfattere trenger egentlig ikke bruke grener, etter min mening – så lenge du ikke gjør forskjellige endringer i mastergrenen samtidig på flere PC-er.
For eksempel bør du fullføre arbeidet ditt på skrivebordet ditt, gjøre forpliktelsene dine og deretter sende endringene til GitHub. Gå deretter til den bærbare datamaskinen og trekk ned alle de nye endringene før du gjør flere endringer. Hvis du ikke gjør det, kan du ende opp med det Git kaller «konflikter». Det er da Git sier: «Hei, det er endringer i GitHub og på denne PC-en som ikke stemmer overens. Hjelp meg å finne ut av dette.»
Å sortere seg ut av en konflikt kan være en smerte, så det er best å unngå det når det er mulig.
Når du først kommer i gang med Git, er det tonnevis av ting du kan lære, som forgrening, forskjellen mellom en appetch og en pull, hva GitHubs pull-forespørsler er, og hvordan du skal håndtere den fryktede konflikten.
Git kan virke komplisert for nykommere, men når du først får taket på det, er det et kraftig verktøy du kan bruke til å administrere og lagre skrivingen din.