Arbetsflöde och Git¶

I denna laborationsserie kommer ni använda Git för att både versionshantera er kod samt för inlämningar. Det är därför bra att ha en god förståelse för hur Git fungerar och följa instruktionerna noga.

Lär er mer om Git här:

På denna sida tillhandahåller vi instruktioner för den användning av Git och GitLab ni kommer behöva under laborationsserien. Det går bra att använda terminalen för att utfärda Git-kommandon och/eller det inbyggda gränssnittet i Visual Studio Code.

Allmäna tips för att undvika problem¶

Använd aldrig git add . , git commit -a eller liknande. Lägg istället till de filer ni vill hantera med git add fil.py fil2.py och gör därefter en commit.
Skriv tydliga commitmeddelanden, det underlättar något enormt när något krånglar.
Använd git status och git log för att se vad som händer, exempelvis innan ni gör en commit för att se om allt är rätt.
Se till att git status säger “Working tree clean” innan ni byter branch eller kör git pull.
Använd aldrig -f om ni inte verkligen vet vad ni gör.

Påbörjande av ny labb¶

Varje laboration ska utföras på en separat branch som ni döper till labX, där X ersätts av laborationens nummer. När ni skapar en branch är det viktigt att tänka på vilken branch ni utgår från. När ni börjar med första labben finns det bara en branch att utgå från, main. När det kommer till de nästkommande labbarna finns det två scenarion:

Föregående labb är godkänd och ni har slutfört merge requesten.
Föregående labb är ej ännu godkänd och ni vill börja med nästa labb ändå.

I fall a) är det bara att utgå från main-branchen eftersom den senaste koden finns där redan.

Detta görs i terminalen med hjälp av

$ git checkout main
$ git pull
$ git checkout -b labX

När det kommer till fall b) kan det bli lite trixigare. Eftersom ni kanske behöver koden från föregående labb kan det vara nödvändigt att utgå från branchen labY, där Y är numret på föregående labb.

$ git checkout labY
$ git pull
$ git checkout -b labX

Det går även bra att använda gränssnittet i VS Code för att checka ut branches genom att klicka på fältet längst ner till vänster:

I bilden ovan är det alltså main som är den aktiva branchen.

Arbete med en labb¶

När ni arbetar med en labb rekommenderas det att kontinuerligt versionshantera er kod, för att ni lättare ska kunna “gå tillbaka” ifall något blivit fel eller försvunnit. Allt arbete med en labb ska ske på en särskild branch, exempelvis labX. Säg att ni gjort några ändringar som ni känner er nöjda med, då är det dags att göra en commit. Börja gärna med att köra

$ git status

Ni kanske då ser att server/main.py och server/readme.md är modiferade, men även att Git har hittat en fil som heter database.sqlite. database.sqlite vill vi inte versionshantera och det är därför viktigt att den inte följer med i någon commit. Vi struntar i den så länge och gör vår commit:

$ git add server/main.py server/readme.md
$ git commit -m "Add User model"
$ git push

Här kan det uppstå ett litet felmeddelande då git push kommer att försöka göra en push mot main grenen. Ni kommer därför behöva sätta er nya branch (lab x) till “default”, detta gör ni genom att använda kommandot som dyker upp i felmeddelandet i terminalen (ni kommer att se ett kommando som börjar med ‘git’ som ni kan använda) läs teminalmeddelandet noga.

För att bli av med database.sqlite när ni kör ``git status`` kan filnamnet läggas till i er .gitignore-fil (se labb 0).

Kommandona ovan finns självfallet även representerade i gränssnittet i VSCode

Fillistan representerar utdatan från git status, ett klick på det lilla plusset vid en fil motsvarar git add och bocken längst upp mostvarar git commit där meddelandet hämtas från textfältet. Klickar ni på knappen ... kan ni även hitta alternativ för att pusha etc.

Parallellt arbete med tidigare labb¶

Valde ni att börja med labben trots att föregående labb inte var godkänd? Då kan ni behöva göra en “merge” för att använda er förbättrade gamla kod i den labben ni arbetar med nu.

Denna procedur representerar alltså pilen markerad med “merge”, längst till höger (vi tar labb 2 och labb 3 som exempel):

Se till att er merge request för labb 2 är godkänd och slutförd (koden finns på main-branchen)
Se till att ni inte har några icke-commitade filer på branchen lab3 (git status visar “On branch lab3, nothing to commit, working tree clean”)
Byt branch till main: $ git checkout main
Se till att er ni har senaste ändringarna: $ git pull
Byt tillbaka till branchen för labb 3: $ git checkout lab3
Gör er merge: $ git merge main.

Detta medför att ändringarna som finns på main också appliceras på lab3.

Oftast kan en merge ske helt automatiskt, men ibland uppstår så kallade konfliker. Det kan vara så att ändringar som påverkar samma rad(er) har skett i både lab3 och på main och då måste ni som programmerare bestämma vilken av ändringarna ni faktiskt vill ha.

En konflikt efter git merge lab2 kan se ut så här i terminalen:

öppnar ni filen som innehåller en konflikt i VSCode kan detta visas:

I detta gränssnitt kan ni enkelt välja vilken av ändringarna ni vill ha kvar genom att klicka på exempelvis “Accept Current Change” för att få med ändringen som gjordes på branchen lab3 men inte den som gjordes på lab2.

öppnar ni filen i en annan texteditor (utan gränssnitt för konflikthantering) ser ni att det helt enkelt har lagts till ett antal rader för att markera konflikten:

För att lösa konflikten kan ni göra följande:

Välja ett alternativ i VSCode (“Accept …”) alternativt ta bort den rad ni inte vill ha i valfri texteditor samt ta bort alla rader med <<<<<<< och >>>>>>>. Gör detta för samtliga filer som innehåller konfliker.
$ git add fil(er)-som-hade-konflikt
$ git commit -m "Merge lab2 into lab3"
$ git push

Nu bör ni ha den godkända koden från labb 2 i er lab3-branch, och det är bara att jobba vidare!

Redovisning¶

Se till att git status matar ut “working tree clean”, d.v.s. att ni har gjort alla commits ni ska och se till att ni har all relevant kod framme och applikationer redo. Får ni sedan godkänt på den muntliga redovisningen kan ni gå vidare till att lämna in koden.

Glöm inte att pusha så att den kod ni redovisade även finns på GitLab.

Inlämning¶

Efter godkänd muntlig redovisning är det dags att lämna in koden så att er labbassistent kan göra en bedömning. Vi kommer använda GitLabs “merge requests” till detta för att kunna ge bra feedback samt ge er övning att använda merge requests inför ert utvecklingsarbete i kommande projekt.

När ni pushat er branch, gå till gitlab.liu.se och navigera till ert projekt. Klicka på “Merge Requests” i sidofältet.

Oftast är GitLab bra på att se att ni nyligen pushat till en branch, och föreslår därför att skapa en merge request för den branchen.

Klicka på “Create merge request”. Ange titlen “Lab X” (byt ut X mot numret på den labben ni lämnar in), eventuell beskrivning samt ange er labbassistent som “Reviewer”. Klicka sedan på “Submit merge request” och invänta bedömning från er labbassistent.

Vill ni uppdatera koden i en merge request är det bara att göra en ny commit på den branchen och pusha till GitLab.

När er labbassistent har hunnit bedömma er inlämning har det antingen tillkommit kommentarer (komplettering), så som i detta fall:

Har ni fått kommentarer behöver ni utföra ändringar, göra commits och pusha till samma branch igen. Meddela därefter er labbassistent via mail att ni genomfört de begärda ändringarna så att hen kan kolla igenom koden på nytt. Ange TDDD83 - Lab X Komplettering som ämne samt bifoga en länk till er merge request. Klicka ej på “Resolve thread”, det är labbassistentens uppdrag.

Alternativt har ni (direkt eller efter några ändringar) fått godkänt, som i detta fall:

Har ni fått godkänt kan ni klicka på “Merge” för att få er kod till er main branch.