Slik kommer du i gang med Git

Det er vanskelig å komme utenom Git hvis man jobber med programvareutvikling. Men det er et verktøy det er lett å komme i gang med. Derfor har vi laget denne guiden for absolutt nybegynnere.

Programvareutvikling er ett av de få fag hvor man har en tidsmaskin i verktøykassen. Snekkeren måler alltid to ganger, for når du først har saget over planken er det ingen vei tilbake. Men det er det i programmering. Vi kan skru tiden tilbake til før vi la til de kodelinjene som fikk alt sammen til å eksplodere i exceptions.

Men programmererens tidsmaskin er nesten mer komplisert enn den fysikken som beskriver hvorfor det ikke er mulig med tidsmaskiner. Og likevel er det ingen vei utenom: Versjonsstyring er uunnværlig.

Uten versjonsstyring er det nesten umulig å jobbe sammen om et programvareprosjekt, og uten versjonsstyring ender man likevel opp med å skulle holde styr på forskjellige versjoner av koden, når man prøver å skrive om en funksjon.

Derfor er det vanskelig å komme utenom Git, som er den utgaven av versjonsstyring som også har gitt navn til kodedelingsnettstedet Github. Men Git er på ingen måte nybegynnervennlig, og det er derfor jeg nå prøver å skrive denne guiden i takt med mitt tredje forsøk på å temme Git-monsteret.

Anta alltid at det er én ting til du må gjøre

Mitt første forsøk strandet på at hvis man på hjemmesiden til Git-prosjektet forsøker å lese veiledningen, så vil man oppdage at den først og fremst forklarer svært detaljert hvordan Git virker – ikke hvordan man bruker Git.

I det hele tatt finner man flere bruksanvisninger som tar utgangspunkt i hvordan Git jobber med å versjonere koden din, i stedet for å ta utgangspunkt i hvordan du jobber.

Det er nemlig det som er det vanskelige med Git. Det er et verktøy til å holde styr på de filene som brukes av applikasjonen din, og Git gjør veldig lite av seg selv. Det er du som må fortelle Git hva som skal være en del av din applikasjon.

Et godt råd er å alltid anta at det er ett trinn mer, enn det du intuitivt ville tro. Å tilføye en fil til prosjektet ditt, er ikke det samme som å lagre filen i prosjektet.

Et annet godt råd er at du ikke bør anta at et begrep eller en kommando i Git gjør det du intuitivt skulle tro ut fra navnet.

Vær også forberedt på merkverdige overraskelser, som for eksempel at du havner i en Vim-lignende editor hvis du glemmer å skrive en commit-beskjed fra kommandolinjen. Og en Vi-lignende editor er ikke hyggelig sted å være (for å komme ut igjen er du nødt til å trykke på escape og skrive :q og trykke enter. Ja, kolonet skal tastes inn – forklaringen til det finner du ett eller annet sted i fortidens Unix-tåke).

Du skal også hele tiden være oppmerksom på hvor du er. Git arbeider med en tre-metafor med grener, så du skal forsikre deg om at du befinner deg på den riktige grenen. Grener kan så vokse sammen med stammen igjen, så det er kanskje mer enn «jernbane-metafor». Er du i tvil, så spør Git hvor du er ved å bruke kommandoen git status, som forteller deg hvilken branch som er aktiv.

Start på Github

La oss starte fra begynnelsen. Først skal du naturligvis laste ned og installere Git. Den biten er ganske grei. Git til Windows inkluderer sin egen utgave av Bash, men Git kan også brukes fra Powershell. Installasjonsprogrammet henviser kun til den klassiske kommandolinjeprompten cmd.exe, men Powershell virker også hvis du installerer Git med standardinnstillingene.

Det neste trinnet er å velge repository. Det er et sted der du lagrer prosjektet ditt. Det kan være en lokal mappe på PC-en din, eller det kan være på en server hos for eksempel Github. Det siste er litt mer komplisert, men det er også det mest nyttige, fordi det er på den måten man kan arbeide flere sammen på samme prosjekt eller på forskjellige datamaskiner. Så jeg vil bruke et Github-repository i min gjennomgang.

I første omgang er det enklest å opprette et nytt repository på Githubs hjemmeside. I det hele tatt så vil jeg anbefale å bruke Githubs brukergrensesnitt til alt som heter administrasjon av repositoryet ditt, da det er lett å miste overblikket og gjøre feil fra kommandolinjen. Det er selvfølgelig en smakssak.

Når du klikker deg inn på ditt nye repository på Github, så er det en stor grønn knapp med teksten «Clone or download». Klikker du på den, får du mulighet til å kopiere en URL som peker til ditt repository. Denne URL-en må du bruke til første trinn i å få laget en lokal klon av filene i repositoryet.

(Artikkelen fortsetter under)

Fra kommandolinjen må du først gå inn i den overordnede mappen der du vil oppbevare filene til prosjektet. Deretter må du bruke kommandoen >git clone etterfulgt av den URLen du kopierte fra Github.

Git henter nå filene fra Github og oppretter en ny mappe med samme navn som repositoryet ditt. Du kan nå gå inn i mappen og jobbe med de filene du har lastet ned, og du kan også tilføye nye filer til mappen.

Ingenting av det du gjør i din lokale mappe påvirker på det nåværende tidspunktet det som ligger på Github.

Legg til filer og endringer med Add og Commit

Med Git må du i første omgang kun konsentrere deg om å holde styr på de endringer du gjør lokalt på prosjektet. For å se hvilken endringer du har gjort på din lokale utgave kan du bruke kommandoen >git status. Den forteller deg hvilke filer som er endret eller lagt til i mappen i den branchen du jobber på akkurat nå.

Når du endrer en fil vil du med statuskommandoen se at filen står som «modified» med rød skrift. På det nåværende tidspunktet har du ikke bedt Git om å lagre endringene.

Første trinn i å gjøre dette er kommandoen >git add etterfulgt av filnavnet. Hvis du føyer til mange filer samtidig så kan du bruke kommandoen etterfulgt av et punktum. Her skal du imidlertid være forsiktig, hvis det ligger filer i mappen som ikke skal være med i prosjektet.

Selv om du har lagt til en fil med add-kommandoen, så er den likevel ikke lagt helt til prosjektet. Det blir den først når du gjør en «commit».

En commit er som et «save game» i et dataspill. Når du har nådd et bestemt punkt hvor det er en god idé å utføre et «save game» som du senere kan vende tilbake til, så gjør du en commit. Det lagrer de endringer du har gjort frem til nå.

En commit samler de add-tilføyelser du har gjort. Når du endrer en fil, så kan du føye til disse til den neste commit med add-kommandoen. Så lenge du ikke har gjort din commit, blir alle adds tilføyd til den neste commit-en du gjør.

Du gjør en commit med kommandoen >git commit -m "", hvor de siste anførselstegnene inneholder en kort beskrivelse av hva det er du har endret med din gjeldende commit. Hvis du utelater beskrivelsen, sender Git deg inn i Vi-editoren, der du kan skrive en lengre beskjed.

Push og pull

På det nåværende tidspunkt er din commit og dine endringer fortsatt kun lokale. Hvis du kun arbeider lokalt med prosjektet ditt, så er det egentlig ikke noe mer du trenger å tenke på med Git. Men hvis du jobber med Github eller et annet eksternt repository, så er det flere trinn.

For å få koden din opp på Github, bruker du kommandoen >git push. Den sender din seneste commit til det stedet du har hentet filene fra, så for Github vil dette være på ditt Github-repository.

En commit er alltid innenfor den branchen du jobber i. Hvis du pusher et commit i en annen branch enn master, så blir den ikke automatisk slått sammen med master-branchen.

Og hvis du ikke har administratorrettigheter til det gjeldende repositoryet, så må du gjøre en «pull request». Et pull henter endringer til en branch og forsøker å flette disse sammen («merge»). Når du gjør en pull request, ber du også administratoren eller dine kolleger om å se igjennom endringene dine og flette dem sammen med deres master-branch.

Du skal også foreta en pull for å hente oppdateringer fra repositoryet. Det gjør du med kommandoen >git pull, som så forsøker å hente endringer og slå dem sammen med din lokale versjon i et «merge».

Merge

Den vanskeligste disiplinen innenfor versjonsstyring er å samle endringer. Git er ganske god til å slå sammen endringene, så lenge det ikke er snakk om tilføyelser eller sletting.

Hvis to personer har endret på de samme linjene, så blir det litt vanskeligere. Git kan ikke gjennomføre en merge før det er tatt stilling til alle konfliktene i filene.

Det finnes verktøy for å gjøre denne etterbehandlingen av konflikter litt mer oversiktlig, men man kan nå ganske langt med Githubs eget webbaserte grensesnitt.

Når det er en konflikt i en fil, vil Git markere linjene det gjelder, og så kan man også gå inn og rette i filene sine og gjøre et nytt forsøk på et commit. Git kan kun se at det er forskjell mellom to versjoner, og så er det opp til deg å beslutte hvilke endringer som skal benyttes.

(Artikkelen fortsetter under)

Branches og merges

Før vi avslutter er det på sin plass å ta en rask prat om branches. En branch er en forgrening av versjonstreet. Det er en kopi av din originale master branch, hvor alle endringer du gjør kun påvirker kopien – inntil du gjør en merge som fletter din branch sammen med master.

Fordelen ved en branch er at du kan jobbe på en ny funksjon eller omskrive en eksisterende funksjon med mulighet for å teste alt på din kopi, uten at det ødelegger den utgaven du vet virker. Derfor har den vanlige praksisen vært å ha en «develop»-branch som man gjør alle endringer i.

I praksis utvikler det seg imidlertid til at man oppretter ytterligere branches fra sin develop-branch, og det kan gjøre strukturen unødvendig komplisert, mener kritikerne av denne modellen. Problemet er at din master-branch ikke har noen vesentlig funksjon på denne måten. Derfor kan det gi mening å droppe sin develop-branch og kun forgrene direkte fra master-branch.

Det er en god måte å gjøre det på hvis man sitter på et prosjekt der endringene skal rulles ut når de er testet og klare. Til større prosjekter kan den klassiske git-flyten være nødvendig, men til mindre prosjekter er det fornuftig med den enklere modellen – hvis man bare sørger for å håndtere merging riktig. Det skal vi vende tilbake til.

For å lage en branch skal man bruke kommandoen >git branch etterfulgt av navnet på den branchen man vil opprette. Du er på det nåværende tidspunkt ikke inne i den nye branchen.

Du skifter til en branch med kommandoen >git checkout etterfulgt av navnet på den branch du vil skifte til. Eller du kan opprette en branch og skifte til den i én operasjon ved å skrive >git checkout -b etterfulgt av navnet på den nye branchen.

For å slå sammen to brancher må du først skifte til den branchen du vil merge til. Du skriver altså eksempelvis først >git checkout master for å skifte til master-branch. Deretter kan du bruke kommandoen >git merge etterfulgt av den branch du vil slå sammen med master.

Det kan være en god idé å først gjøre en merge fra master til den branchen du har arbeidet på. Så kan du løse eventuelle konflikter i denne branchen, før du igjen merger din branch med master.

Arbeidsflyten

For å oppsummere, så vil man første gang man begynner å redigere på et prosjekt starte med clone. Men når du senere vil arbeide videre på prosjektet, så er det en god idé å begynne med å gjøre et pull for å hente de siste endringene fra repositoryet.

Deretter vil du gjøre en add hver gang du tilføyer filer eller er ferdig med å redigere en fil. Når du er kommet til et punkt der en oppgave er avsluttet, så vil det være en god idé å gjøre en commit.

Avslutt deretter med å gjøre et push for å sende alle dine commits til repositoryet.

Bruk branches til større endringer, men vær oppmerksom på at det er flere måter å organisere bruken av branches på med Git. Du bør også være oppmerksom på at alt blir «addet» og «committet» i din branch, helt til du gjør et merge.

Versjonsstyring gir som nevnt mulighet til å gå tilbake til en tidligere versjon hvis du roter til ting for mye. Det er imidlertid noe som krever at man holder tungen rett i munnen, for det er fort gjort å gjøre en endring som ikke er mulig å reversere senere.

Den enkleste måten er å bruke kommandoen >git log eller >git reflog for å få en oversikt over commits. Den siste av de to gir en hashverdi som kan brukes som referanse, og viser kun commits man kan gå tilbake til.

Deretter kan man bruke >git checkout etterfulgt av hashverdien til den commit du ønsker å vende tilbake til, og eventuelt navnet på den gjeldende filen.

Det finnes andre måter å gå tilbake på, men checkout er den måte som er sikrest for den enkelte utvikler.

Jeg har brukt Git under arbeidet med denne artikkelen, så den kan faktisk også finnes på Github. Det er et poeng i seg selv, ettersom versjonsstyring også kan brukes utenfor programmering – for eksempel hvis man er flere personer som jobber med en samling med dokumenter.

Det krever imidlertid at alle forfatterne er forberedt på å lære ikke bare en håndfull kommandoer, men også en streng arbeidsflyt som krever litt øvelse å mestre.

Denne artikkelen er levert av vår samarbeidspartner Version2.