Fremgangsmåten under ser ut til å fungere best for github. For bitbucket anbefales deres egne instruksjoner som blir presentert når du oppretter et repository for første gang. Seksjonen om SSH-nøkler for passordløs synkronisering fungerer som beskrevet for både bitbucket og github.

Bruk av git

Dette er en kort guide for å komme i gang med git på Ubuntu/linux. Den vil ta for seg kun det aller mest grunnleggende som er nødvendig for å komme i gang med enkel bruk av git.

Kort om git

Git er et såkalt Source Code Management system, utviklet av selveste Linus Torvalds i 2005, som lar brukere redigere filer fra en mappe på en server, et såkalt repository (slang repo,) samtidig. Dette er et veldig effektivt verktøy når flere jobber sammen på store programmeringsprosjekter og kan være et godt alternativ til Dropbox. Hvis man legger litt tid ned i å lære seg det skikkelig så har man et proffesjonellt verktøy med uant rekkevidde, men når det er sagt så er terskelen for å komme i gang i en mindre skala veldig lav. Man får mye ut av git ved å bare kunne en håndfull (altså fem, 5) kommandoer. For å lese mer om git og dets opphav, se wikipedia.

Komme igang

For å komme i gang med git oppretter man en bruker med stud-eposten på enten bitbucket eller github. Til utdanningsformål anbefales førstnevnte ettersom disse tilbyr deg en profesjonell konto med ubegrenset antall repositories og mulighet for private repositories som bare er synlige for de du deler dem med dersom du registrerer deg med stud-adressen din som e-post. Det samme tilbudet må du betale for i github. Når du oppretter en brukerkonto for første gang, kan det være at du blir tilbudt en tutorial på git fra siden. Du kan velge selv om du vil følge den eller fortsette med å følge stegene på denne siden. Det kan kanskje være greit å gjøre begge siden fremgangsmåtene kanskje er litt forksjellige slik at man da kan plukke litt flere git-funksjoner.

Opprette et repo

Når du skal opprette et repo gjøres dette enkelt og greit fra enten githubs eller bitbuckets web-grensesnitt. I bitbucket velger du fra toppmenyen "Repositories → Create repository", mens github ligger dette under "+ → New repository". Huk av for "private repository" hvis du ønsker dette. Github lar deg også opprette et repo med en README-fil. Da kan du clone repositoriet med en gang lokalt til maskinen hvis du ønsker det.

Synkroniser et repository for første gang med git clone

For at du skal kunne synkronisere på vanlig må det først være en fil i repositoriet. Dette kan du opprette i repositoriet på bitbucket.org eller på github.com, alt ettersom hvilken av disse du velger å benytte. Når dette er gjort, kan du hente en lenke fra siden til repositoriet ditt. Du har to valg, SSH eller HTTPS. Hvis du benytter deg av HTTPS må du skrive inn passord for hver gang du vil synkronisere fra maskinen din. Dette slipper du med SSH, men da må du først gjøre noen sprell i terminal. Vi går igjennom begge metodene her, men først må du sørge for at git er installert på maskinen din. Dette kan du sjekke fra egen maskin med å kjøre kommandoen

git --version

og se om den skriver ut et versjonsnummer eller om du får "git: command not found". Dersom sistnevnte er tilfellet kan du installere ved å kjøre

sudo apt-get install git

Hvis du sitter på en av maskinene på null- eller banachrommet så er git installert fra før av. Git er også installert på beregningsserveren markov.

HTTPS

Fra siden til repositoriet ditt finner du en nedtrekksmeny på høyre side hvor det står enten SSH eller HTTPS. Velg HTTPS og kopier lenken. Lenken burde se ut som dette når du bruker bitbucket: https://dittBrukernavn@bitbucket.org/dittBrukernavn/dittRepoNavn.git. Deretter navigerer du i terminal til den mappen som du vil synkronisere til cd-kommandoen. Eventuellt oppretter du mapper med mkdir-kommandoen og deretter navigerer dit. Når dette er gjort kan vi klone repostioriet første gang med kommandoen

git clone https://dittBrukernavn@bitbucket.org/dittBrukernavn/dittRepoNavn.git

Du blir nå bedt om å skrive inn passordet ditt til github/bitbucket og kloningen burde starte etter dette. Når kloningen er ferdig inneholder mappen det samme som du finner på siden til repositoriet ditt.

SSH

Dette er noe mer omfattende enn HTTPS, men frykt ikke! Det hele er gjort med noen få kommandoer og resultatet er at det blir mer behagelig fordi man slipper å taste inn passord hver gang man skal synkronisere. For å bruke SSH, må vi først kopiere en public RSA-key fra maskinen vi sitter på og legge den inn på kontoen våres på bitbucket/github. Aller først må vi sørge for at SSH er installert på maskinen. Igjen, hvis du sitter på en av maskinene på matteland så vil SSH allerede være installert. Hvis ikke kan du sjekke dette ved å kjøre kommandoen

ssh -V

Hvis ssh er installert vil denne kommandoen gi ut et versjonsnummer. Hvis ikke vil du få en feilmelding. Da kan må du installere ssh ved å kjøre kommandoen

sudo apt-get install openssh-client

Når dette er klart må vi kopiere innholdet i en public RSA-nøkkel fra maskinen. Eventuellt må denne RSA-nøkkelen opprettes først. I terminal navigerer vi til mappen ~/.ssh og sjekker innholdet med kommandoene

cd ~/.ssh
ls

Hvis innholdet

id_rsa  id_rsa.pub  known_hosts

kommer opp etter at du har kjørt ls er alt klart for neste steg. Hvis mappen ikke eksisterer eller den ikke inneholder noe, må disse opprettes. Dette gjør man enkelt med kommandoen

ssh-keygen

du blir her spurt om nøklene skal passordbeskyttes og lignende. Dette er ikke nødvendig, men du kan gjøre det om du vil. Nå skal du kunne kjøre kommandoene over på nytt og få opp innholdet som vist over. Vi åpner så filen id_rsa.pub i en teksteditor og kopierer hele innholdet i filen. Dette gjør du fra terminal ved å kjøre kommandoen

gedit id_rsa.pub

og så markere hele innholdet og deretter kopiere. Når dette er gjort går du til siden din på bitbucket/github. På bitbucket trykker du på profilen din øverst til høyre og velger "Manage Account" og velger deretter "SSH keys" i venstre kolonne. Trykk "Add key" og lim inn innholdet fra id_rsa.pub for så å lagre. På github velger du "Settings" øverst til høyre og deretter "SSH keys" i venstre kolonne. Trykk "Add SSH keys" og lim in innholdet fra id_rsa.pub for så å lagre.

Nå skal alt være klart til å klone for første gang med SSH. Gå til nedtrekksmenyen på siden til repositoriet ditt og velg SSH istedenfor HTTPS. Kopier denne lenken. Denne lenken burde se slik ut: git@bitbucket.org:dittBrukernavn/dittRepoNavn.git hvis du bruker bitbucket. Deretter navigerer du i terminal til den mappen som du vil synkronisere til cd-kommandoen. Eventuellt oppretter du mapper med mkdir-kommandoen og deretter navigerer dit. Når dette er gjort kan vi klone repostioriet første gang med kommandoen

git clone git@bitbucket.org:dittBrukernavn/dittRepoNavn.git

Når kloningen er ferdig inneholder mappen det samme som du finner på siden til repositoriet ditt.

Synkronisering av filer etter at repo er opprettet

Når et repo er opprettet kan du jobbe lokalt på maskinen i denne mappen som normalt. Det betyr at du kan oprette og redigere filer slik som du ellers ville gjort. Når du vil synkronisere endringer mot repositoriet ditt gjøres dette enklest ved å utføre noen kommandoer i et terminalvindu.

Åpne et terminalvindu og naviger til mappen hvor repositoriet ditt står. For å gjøre klar endringer til synkronisering bruker vi en kommando som heter "add". Skriv

git add .

I terminal er "." som kjent en peker til den mappen du står i nå (ref [ https://wiki.math.ntnu.no/drift/stud/linuxkommandoer | linux-guide]). Det betyr at ved å skrive denne kommandoen, så vil git "scanne" gjennom hele mappen du står og klargjøre alle endringer for synkronisering. Om du kun vil klargjøre mappen "foo" eller filen "bar" bytter du bare ut "." med en av disse.

Neste steg er da å committe endringene. En commit lager en "pakke" med selve endringene sammen med en tekststreng som brukeren definerer. Denne tekststrengen vil da komme opp i repositoriet på enten bitbucket eller github under synkroniseringsloggen og dermed ment som et verktøy for å holde oversikt over hva endringen inneholder. For å bruke commit skriver i terminalvinduet

git commit -m 'din forklarende tekst med oversikt over endringer'

Om du her skulle glemme "-m"-flagget og tekststrengen vil du få opp en teksteditor hvor du må skrive en tekststreng og så trykke lagre. Dette fungerer dårlig om du jobber på f.eks. beregningsserveren markov da denne ikke har noen definert skjerm og dermed ingen plass å åpne teksteditoren. Vi anbefaler derfor at du bruker metoden nevnt over da denne er mest generell og vil fungere i så og si alle miljøer.

Når du så har laget en commit-pakke som forklart over er det klart for siste steg, nemlig å sende pakken med endringene og beskjeden til selve repositoriet med kommandoen push. Dette blir da gjerne kalt å "pushe" endringen. I terminalvinduet skriver du

git push

I bitbucket kan det i noen tilfeller være nødvendig med flere flagg i push kommandoen

git push -u origin

vil da fungere. Om du har lagt inn SSH-nøkler som beskrevet i seksjonen over så vil endringene sendes til repositoriet med en gang. Om du har HTTP som synkronisering er du nødt til å verifisere med brukernavn og passord først.

For å se om du har noen som er "staget" for en push kan du bruke kommandoen

git status

Synkronisering fra repo til maskin

Om du har klonet repositoriet til forskjellige maskiner eller om du samarbeider kan det være at du vil hente ned endringer som er pushet av andre eller som du selv har pushet fra en annen maskin. Dette gjøres ved å bruke "pull"-kommandoen på følgende måte

git pull

Da vil ditt lokale repository synkroniseres mot repositoriet i bitbucket eller github.

Flytting og sletting av filer

Om du vil flytte eller slette filer kan du gjøre dette grafisk fra sidene til repositoriet ditt hos bitbucket eller github. Du kan også bruke de vanlige kommandoene i terminal hvis du bruker "git"-kommandoen foran de vanlige manipulasjonsfunksjonene. F.eks. om du vil slette filen "foo" kan du skrive

git rm foo

Da skal denne filen også slettes fra repositoriet neste gang du pusher en endring. Om du kun bruker "rm foo" på vanlig vis vil git tolke dette som at filen mangler neste gang du bruker pull og filen vil dukke opp igjen. Det samme gjelder om du vil endre filnavn ved å bruke kommandoen mv. La oss si du vil endre filnavnet foo til bar. Da må du bruke kommandoen

git mv foo bar

Om du ikke bruker git-kommandoen foran så vil git ved neste endring tolke dette som at du har opprettet filen "bar" og at du har mistet filen foo. Da vil foo hentes tilbake fra bitbucket/github ved neste pull og filen bar blir opprettet hos bitbucket/github ved første push.

Tips, triks, generelle retningslinjer og en tilhørende disclaimer

Dette var en meget kort intro som kun dekker de mest basale kommandoene i et meget kraftig verktøy som inneholder en horde av funksjonalitet. Det kan oppstå en del kluss om flere personer jobber mot samme repo og gjør endringer på samme fil. Da vil uforsiktig pushing og pulling føre til at repositoreiet på bitbucket/github mottar forskjellige utgaver av samme fil og konflikter oppstår. Dette kan løses enkelt ved å passe på at flere ikke jobber på samme fil samtidig og passe på at

DU BRUKER git pull FØR DU GJØR KLART FOR Å PUSHE ENDRINGER

Om man vil være mer proff, så har git funksjonalitet for å lage "branches" slik at forskjellige bidragsytere kan jobbe parallellt på hver sin gren av repositoriet for deretter å "merge" disse når man ønsker. Dette blir fort litt mer avansert, men git er som sagt et meget kraftig verktøy som er brukt i mange store utviklingsprosjekter (f.eks. mye brukt i linux-miljøet). Om du er interessert i dette anbefaler forfatteren en liten google-bonanza.

Om feil og konflikter oppstår kan dette ofte løses med litt googling. I værste fall er en quick-fix ofte å flytte unna filen det gjelder til en mappe utenfor git for deretter å slette den i repositoriet enten fra sidene til bitbucket/github eller ved å bruke "git rm filnavn" som nevnt i seksjonen over. Når dette er gjort kan riktig fil legges tilbake i repositoriet og synkroniseres på nytt. Dette er ikke en veldig elegant løsning, men den fungerer i de fleste tilfeller om du ikke ønsker å sette deg inn i litt ekstra tilleggsfunksjonalitet i git.

2015-01-27, geiramh