Bruk av Git i Inf101

Git er et versjonskontrollverktøy, som blant annet brukes av Linux kernelen, og som vi skal bruke mye av i inf101. Git følger med i Eclipse, men kan også brukes som eget verktøy eller fra kommandolinjen. Du finner installasjonsinstruksjoner her.

For å lære Git-kommandoene anbefaler vi tryGit.

Sentrale begreper

• Arbeidskopi/mappe – en mappe på maskinen din der du har én versjon av filene dine (typisk den nyeste versjonen), eventuelt med endringer du holder på å gjøre. Eclipse jobber direkte mot arbeidskopien din.
• Repositorium – en full kopi av all historikken til alle filene i et Git-prosjekt. Hver Git arbeidskopi inneholder også et repositorium, og lar deg bytte/oppdatere hvilken versjon av filene du ser. Hver bruker som jobber på samme prosjektet har en kopi (klone) av repositoriet, og ofte (inkl i INF101) har vi også et "master"-repositorium som ligger på en sentral server.
• Push/pull – å sende endringer fra et repositorium til et annet.
• Server/GitLab-server – en maskin med sentral lagring av Git-repositorier. Hos oss er det retting.ii.uib.no

I INF101 vil du typisk forholde deg til:

• For forelesningene: med undermapper med Eclipse-prosjekter for hver forelesning; vi har et master-repositorium her på GitLab-serveren, og du kan ha din egen klone av dette repositoriet, som du oppdaterer for å se de nyeste endringene (hvis du gjør endringer selv, kan du ikke sende dem tilbake)
• For øvelser du gjør: Ett Git-prosjekt for hver øvelse, som vi automatisk kloner til et eget privat Git-prosjekt for hver student. Hvert Git-prosjekt inneholder ett enkelt Eclipse-prosjekt. For hvert prosjekt har du et master-repositorium på GitLab-serveren, samt klonede repositorier på datamaskinen(e) du bruker til daglig. Siden du har ditt eget prosjekt/repositorium på serveren, kan du når som helst sende endringer tilbake dit.
  • Hver gang du har gjort noe på en oppgave, må du committe det du har gjort og pushe det til GitLab-serveren.
  • Hvis du bruker flere datamaskiner, bør du være nøye med å pushe før du forlater den ene maskinen, og så pulle på den andre maskinen for å få nyeste versjon av det du jobber på
  • Hver gang du pusher, gjør du det mulig for oss å se på det du har gjort hvis du trenger hjelp.
  • På begynnelsen av hver øvelse/semesteroppgave vil det også stå detaljert forklaring på hvordan du går fra for å hente oppgaven osv.

Litt mer bakgrunn

Ofte når man lager prosjekter på datamaskin håndterer man mange forskjellige versjoner samtidig. Si at man skriver en artikkel. Da kan artikkelmappa på datamaskinen din se slik ut:

Her er det flere versjoner av teksten som blir tatt vare på. En grunn til å ta vare på flere versjoner er for å passe på at arbeid ikke går tapt, men noen ganger er det for å kunne ha flere "nesten ferdig" versjoner. For eksempel vil som oftest en artikkel måtte bli sett gjennom flere ganger av en redaktør.

I programutvikling blir det å ta vare på flere versjoner mye vanskeligere. Programmer utvikles og vedlikeholdes over flere år og ofte er flere forskjellige versjoner av programmet i bruk samtidig. Linux kernelen har over 14000 forfattere, gir ut en ny versjon annenhver måned og består av over 16 millioner linjer med kode!

Det er derfor nødvendig å ha en systematisk tilnærming til versjonskontroll. For dette bruker Linux kernelen verktøyet git. Dette kommer vi også til å ta i bruk i inf101. Dette verktøyet er veldig avansert. Derfor gir vi en nokså forenklet introduksjon til git under som noen ganger inneholder noen halvsannheter. Det burde likevel være nokk til å kunne jobbe effektivt med git.

Repository, Branch og Commit

Et git repository er en versjonsamling for prosjektet ditt. Prosjektet består av et fil-tre (mapper og filer). Versjonene består av commits. En commit består av en revisjon av prosjektet (filer lagt til, filer fjærnet eller filer modifisert), og en commit beskjed. Commit beskjeden beskriver hva som er forandret.

En branch er en utviklingsgren som består av en serie med commits. Alle prosjekter har (som regel) en hovedbranch kallt master.

Over har vi et enkelt eksempel på et git prosjekt. Det er en branch kalt master. Den inneholder 4 commits. Tilsvarende vil filtreet for de 4 versjonene av prosjektet se ut som følger:

Staging

Som oftest er det flere filer i prosjektmappa de som du ikke ønsker at skal versjonkontrolleres. For javaprosjekter gjelder dette spesiellt ".class" filer. Hvis disse inkluderes skaper det bare unødvendig arbeid for oss å passe på at ".class" filen alltid er oppdatert. Vi kan jo uansett generere de ved å kompilere ".java" filene. Når du bruker Git sammen med Eclipse vil Eclipse som regel selv sørge for at ".class"-filene holdes utenom.

Derfor kan du velge hvilke filer som skal håndteres av git, og hvilke filer som skal være med i hver commit. F.eks. kan forandringer i to filer bli gitt hver sin commit.

Med git begynner man med et filtre som tilsvarer den siste commiten i en branch. Fra dette gjør kan man flere forandringer: nye filer, modifiserte filer, slettede filer. Så legger man til en commit på enden av branchen med (ikke nødvendigvis alle) forandringene man har gjort. I terminal vinduet gjør man dette ved å bruke kommandoen git add etterfulgt av de filene som skal være med i commiten. Så bruker man kommandoen git commit hvor man så blir bedt om å skrive inn en commit beskjed som beskriver hva som commiten gjør.

Det finnes flere grafiske grensesnittet for git. Du kan godt bruke et av disse, eller det grafiske grensesnittet for git som er integrert i Eclipse på "Team"-menyen.

Remote Repositories

Ofte har man et repository som finnes på en annen datamaskin, og som man håndterer indirekte. Flere nettsteder tilbyr gratis lagring av slike repositories, f.eks. GitHub og Bitbucket. Vi bruker en egen Git-server på instittet, basert på GitLab.

Push

En av de kommandoene som er til for håndtere remote repositories er push. Dette sender nye commits fra en branch i det lokale repositoriet til det remote repositoriet. Dette kan kun gjøres hvis den lokale branchen er foran det remote repositoriet. Dvs. det er ingen commits på remoten som ikke også er tilstede lokalt.

Over ser vi et tilfelle der en push operasjon er mulig. Den lokale master branchen inneholder 4 commits, men bare to av de finnes på den remote master branchen. Etter at kommandoen git push remote master blir kjørt vil de to manglende commitene bli lagt til på remoten.

Merge

Med push er det enkelt å overføre commits fra en branch til en annen, siden det bare mangler noen commits i remote branchen kan vi bare legge de til på enden, men hva hvis begge brancher inneholder et set med commits som ikke er i den andre? Da trenger vi å slå sammen forandringene. Dette er hva vi kaller en merge. Hensikten med en merge er å påføre de forandringene som er gjort i en branch inn i en annen branch. La oss si at branch A skal merges inn i branch B. Etter mergen skal alle forandringer som er gjort i A også være gjort i B. Da ser git etter det som kalles en konflikt. Dvs. en linje i en tekst fil som A og B er uenig om hva skal være. Med andre ord det er to commits, en som er i A men ikke B og en som er i B men ikke i A, og begge forandrer samme linje. Da ber git oss om å velge hvilken forandring som er gjeldene.

Etter merge operasjonen er det en commit på slutten av B branchen med de forandringene vi har valgt å beholde fra mergen.

Her trengs det helt klart et eksempel!

La oss si vi har den følgende tekstfilen i utganspunktet.

My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the year.

i A branchen ser tekstfilen slik ut:

My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the yar.

Mens i B branchen ser tekstfilen slik ut:

My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the year

I B branchen har vi fikset skrivefeilen med ordet "year". I A branchen har vi lagt til et punktum.

Hvis vi ber git om å merge A inn i B sier den at det er en konflikt i filen og ber oss om å fikse det. Åpner vi filen med en teksteditor ser den slik ut:

My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
<<<<<<< HEAD
The darkest evening of the year
=======
The darkest evening of the yar.
>>>>>>> A

Her ser vi hva som er i B branchen (begynner med <<<<<< HEAD og slutter med =====) og det som er i A branchen. Vi må så editere tekst filen for å vise hvilken av versjonene som vi vil beholde. (Her bør det nevnes at det er god praksis å ikke introdusere flere forandringer enn de som enten er i B branchen eller i A branchen, så ikke både legge til punktum og fikse skrivefeilen eller legge til flere vers osv. Dette kan man gjøre senere.) Etter at vi har valgt hvilken versjon å behold bruker vi git commit kommandoen for å fullføre mergen og legge til commiten som gjør forandringene vi har valgt.

Pull

Pull kommandoen brukes for å hente forandringer i en branch i et remote repository. La oss si at du har lyst til å hente forandringene som er i et remote repository på branchen som heter branch-a. Lokalt har du en kopi av denne branchen (den heter også branch-a hos deg), men den mangler noen commits som er på remote repositoriet. git pull remote branch-a gjør da to ting. Først henter den forandringene slik at de er lagret lokalt i en branch som heter "remote/branch-a". Så vil den merge remote/branch-a inn i branch-a. Nå kan det hende at du har gjort noen forandringer i din branch-a som konflikterer med remote/branch-a, og da er det nødvendig å fikse denne konflikten akkurat som vi har gjort tidligere.