De aller fleste som har drevet med prosjekter har på ett eller annet tidspunkt endt opp med en mappe struktur for dokumenter som ser omtrent slikt ut.

Dette er på mange måter ikke noe feil med å ha lagret flere revisjoner av filer på denne måten. Men det er noen problemer.

For det første kan et prosjekt potensielt ta veldig stor plass på diskene dine.

For det andre kan det fort bli uoversiktlig hva som faktisk er den siste versjonen av filene.

Om man er den eneste som jobber med filene i ett prosjekt kan dette sikkert gå greit siden man stort sett klarer å holde oversikt i sitt eget rot. Men det store problemet oppstår når flere personer i ett team skal samarbeide på de samme filene i ett prosjekt. Da blir det for mye rot og dårlig stemning.

Git prøver å løse problemet med revisjoner på en smidig måte. I stedet for å lagre en ny kopi av filen som ble endret, tar git å lagrer endringene som ble gjort på en fil siden sist gang den ble lagret som en revisjon. Dette er spesielt nyttig på software prosjekter med kildekode, siden det stort sett bare er noen linjer med kode som blir endret fra revisjon til revisjon.

Siden man i tillegg kun lagrer endringene fra gang til gang, er det veldig raskt å gjøre en endring. Hvis det vise seg at man angrer på denne endringen er det like lett å gå tilbake til forrige revisjon.

For å starte å bruke git er det noen ting som må på plass.

1. Du må installere git
2. Git må konfigureres med hvem du er

Når dette er på plass kan starte å jobbe på ett prosjekt og du koble prosjekte opp mot github, bitlab, bitbucket eller lignende for arkivering og for at andre skal kunne bidra på prosjektet.

I denne guiden tar vi utgangspunkt i at det utvikles på en Ubuntu Linux maskin. Men bortsett ifra selve installasjonen er bruken av git lik for alle operativsystem, inkludert Windows.

Vi starter med å installere git:

Når git er installert kan du verifisere med hvilken versjon du har installert.

Nå må du legge inn ditt navn og din epost i de globale git instillingene for din bruker på datamaskinen.

For å kontrollere at innstillingene ble registrert kan du kjøre denne kommandoen

Da er det bare å starte bruke git.

Vi starter dette lille demo prosjektet ved å opprette en mappe i home folderen, og navigerer inn i den mappen.

Denne mappen blir roten i git prosjektet vårt. Git vil følge med på endringer som skjer i filene og undermappene til denne rot mappen.

For at git skal fungere må det initialiseres i denne mappen.

Dette oppretter en skjult mappes som heter .git. Denne mappen inneholder alle de nødvendige filene som må til for at git skal fungere. Filene i denne mappen skal du ikke gjøre noe med direkte. De vil bli oppdatert automatisk når du bruker git kommandoer. Derfor kan du i stor grad bare late som om den ikke eksisterer.

Nå kan vi opprette prosjektets aller første fil:

Nå er filen opprettet, men hvis vi sjekker status på git prosjektet kan vi se at filen ikke er lagt til i prosjektet.

Som du kan les utifta terminaldumpen over er filen untracked. Det vil si at endringer i denne filen blir ikke overvåket av git. For at denne filen skal bli overvåket må den legges til i git prosjektet.

For å legge til alle nye filer i prosjektmappen til i prosjektet kjør følgende kommando:

Hvis vi sjekker statusen til git, vil vi se at filen er lagt til i prosjektet og er klar til å bli committet.

Utifra teminal dumpen over kan vi ved å lese nedreste linje se at filen er lagt til i "staging" og er klar for å bli committed. Å commite er git sjargong for arkivering.

For å commite filen skriver vi denne kommandoen:

Gratulerer! Du har gjort din aller første commit! Hvis vi sjekker status på git prosjektet vil vi se at det ikke er noen nye endringer siden forrige commit.

For å demonstrere hvordan git fungerer sletter vi den andre linjer og legge til en ny linje med tekst.

Hvis vi nå sjekker status på prosjektet kan vi se at git har registrert at filen har blitt endret siden forrige commit.

For å se nøyaktig hva som ble endret kjøres denne kommandoen:

Over kan vi se nøyaktig hva som har blitt endret siden forrige commit. Linjen med minus foran har blitt fjernet og linjen meg pluss foran har blitt lagt til.

Nå kan vi commite denne endringen:

Som du ser av terminal dumpen over vil du få ett sammendrag av hva som ble endret i denne commiten.

Github er en populær plattform for gratis arkivering av prosjekter. I tillegg er det en fin måte samarbeide om ett prosjekt på.

Måten man bruker git på er ikke så veldig intuitivt i starten. Men jo mer man bruker git og jo flere prosjekter man jobber på med git, jo mer skjønner man hvorfor det er designet som det er og hvor genialt det faktisk er.

De aller fleste git prosjekter har ett origin, eller ett hovedsted det arkiveres. I denne guiden skal vi bruke GitHub, men det finnes mange alternativer som GitLab og BitBucket. Alle har sine styrker og svakheter. Her har jeg valgt å bruke GitHub siden det er gratis og kanskje lettest å komme i gang med.

Når du blir med i ett team som jobber med ett prosjekt starter man med å laste ned en kopi, eller en klone av prosjektet. Navnet som bruker på prosjektene er er repo, som er kort for repository. Etter hvert som man jobber på ett prosjekt må man "pulle", eller hente ned endringene som de andre i teamet har gjort fra origin (GitHub) til din datamaskin før man kan bidra med endringer.

Når du er ferdig med endringene man ønsket å gjøre på prosjektet må du "pushe" eller sende endringene dine til origin (GitHub) slik at de andre i prosjektet kan får tilgang til endringene du bidro med.

Om man ikke ønsker eller trenger å samarbeide med andre utviklere på ett prosjekt er git i kombinasjon med GitHub en fantastisk måte å ta backup av av prosjekter på.

Mange utviklere bruker GitHub som en form for sosialt media for å vise frem hvilke prosjekter de jobber med på fritiden. Det er mange grunner til at man gjør dette. En av de er for å vise frem prosjekter til venner og kolleger. Å vise frem prosjektene dine kan være en fin måte å vise frem ferdighetsnivået ditt, og hvordan du velger å løse problemer på.

Når du har opprettet en bruker på GitHub kan opprette ett repo der som vi kan bruke som orgin til det lille prosjektet vårt.

Det første du gjør er å opprette ett nytt repo som du gir ett meningsfullt navn, og velger om skal være privat, eller offentlig.

I mange tilfeller velge man å gjøre repository'et privat fordi det skal inneholde filer med databasepassord osv. Men det finnes metoder som gjøre at du ikke trenger å publisere sensitiv informasjon med ett repo. Dette utenfor scopet til denne guiden, så det vil jeg ikke skrive noe om her.

Når du har gått videre vil GitHub vil presentere tips for hvordan du kan få github repoet satt som origin til det lokale repoet. Denne guiden er ikke helt rett.

For å definere hva som er origin til prosjektet kjører vi starter vi helt enkelt med å kopiere den første kommandoen GitHub foreslår:

Nå er det bare å pushe det lokale repoet til origin, som i dette tilfelle er github repoet vårt.

Første gang man skal pushe til origin fra en local branch må man definere hva som er upstream for den lokale git branchen. I dette tilfellet vil det si at den lokale master branchen skal bruke master branchen hos origin som upstream.

Når man pusher til github må man autentisere ved å oppgi brukernavn og passord. Når GitHub har godkjent autentiseringen vil git fullføre pushet til origin.

Hvis vi laster på nutt GitHub siden vi var på, vil du se att filen nå ligger på GitHub.

Da har du et komplett prosjekt med localt repo og origin repo, som du kan jobbe med!

Hele poenget med GitHub er at man kan bruke det som en backup løsning, eller som et verktøy for samarbeid.

For at origin som ligger på GitHub skal bli oppdatert må man "pushe" de lokale endringene til GitHub, slik at repoet der blir oppdatert.

Dette kan vi teste med å legge til en ny linje på filen vår

Så committer vi endringen til filen

Så kan vi pushe endringene slik at de havner på GitHub.

Hvis vi nå tar en titt på filen på GitHub, vil du kunne se endringene.

På denne måten kan du fortsette med prosjektet ditt. Du endrer på filer, committer endringene til ditt lokale repo, og pusher det lokale repoet slik at GitHub repoet blir oppdatert.

Hvis det er noen andre som deltar på prosjektet pusher endringer til GitHub må du oppdatere ditt lokale repo (slik at det er likt med det som ligger på GitHub), før du kan pushe endringene du har lokalt til GitHub.

Som vi kan se utifra terminal dumpen var den en ny linje som var lagt til. Leser du du filen nå, vil du se at den er oppdatert.

En av de store fordelene med å jobbe på GitHub og andre lignende plattformer er at det er veldig lett å få oversikt over hva som er gjort på prosjektet. Hvis du trykker på commits knappen i github kommer du til loggen over commits på prosjektet.

Her kan man se hele commit loggen til git repoet.

Hvis du trykker på committen kan se nøyaktig hva som ble endret i den committen.

Her kan du se nøyaktig hvilken linje det ble gjort endringer på. I dette tilfellet ble det lagt til en ny linje.

Mye av det som gjør git så populært er at man kan gå tilbake i tid, til en tidligere versjon av en fil. Men for at det skal være lettvint på prosjekter med mange commits er det noen regler som bør følges.

1. La en commit kun inneholde en endring. Det vil si at hvis du skal endre footeren på en webside bør du committe hver del av den jobben. En commit kan være å flytte på noe tekst, en annen commit kan være å endre farge på den teksten.
2. Skriv gode og beskrivende commit beskjeder. Tenk over at du og andre skal kunne finne en endring i prosjektet ved å lete i commit loggen og finne endringen basert på commit beskjeder. En commit beskjed alá: "oppdaterte footer" gir lite mening når footeren på nettsiden har blitt oppdatert mange ganger iløpet av prosjektets levetid. Fortell nøyaktig hva som ble endret i footeren alá "footer: endre farge på linker"
3. Skriv i commit beskjeder i nåtid. En commit inneholder en endring. Tenk over at når du leter git commit loggen for å finne enn commit vil du lese det som "denne commiten gjorde 'denne' endringen på prosjektet".

Når det er flere som skal samarbeide på ett prosjekt er det lurt å avklare arbeidsoppgaver slik at dere ikke jobber på samme fil samtidig. Hvis man ikke følger dette rådet blir det fort problemer når man skal flette sammen endringene. I praksis vil det si at ett prosjekt må deles opp i filer som tar seg av spesifikke deler av prosjektet.

Når man jobber med prosjekter i git skjønner man fort hvorfor det er en fordel å ha prosjektet delt opp i små filer for å sikre god prosjektflyt. Ved at hver fil inneholder kun en spesifikk del av prosjektet reduserer man sannsynligheten for at man må vente på hverandre eller at man får problemer med å flette sammen commitene. Dette er noe man uansett er tjent med siden det også blir lettere å lese koden.