I følgende Workshop bliver I guidet igennem hvordan man bruger git (fra terminalen), GitHub, og hvordan man laver et fælles projekt alle I gruppen kan biddrage til.
Alle i gruppen skal have git installeret på sin PC (hvis det ikke allerede er gjort): https://git-scm.com/downloads
Når du har git installeret, er det en god idé at sørge for, at git kender dit brugernavn og din rigtige email. Det skal bruges så man nemt kan se hvem der har lavet hvilket ændringer med git på et fælles projekt.
Fra terminalen skal du bruge følgende to kommandoer. Du har muligvis gjort det tidligere, men du kan altid gøre det igen for at være på den sikre side. I det følgende skal du erstate <name> med dit navn. Du vælger selv om du vil bruge dit fulde navn eller noget andet. Og du skal erstatte <email> med den email du vil have tilknyttet til dit arbejde i git.
git config --global user.name "<name>"
git config --global user.email <email>
Derudover er det godt at fortælle git hvilken editor man foretrækker til redigering af tekst og kode. Det kan du fortælle git sådan her (hvis du bruger vscode):
git config --global core.editor "code --wait"
Til en start skal I alle prøve at lave et git repository.
Lav en tom folder på din PC. Smid nogle filer i folderen med noget tekst eller kode, som du potentielt vil dele med andre. Fx noget JavaScript. Det er ikke så vigtigt hvad du vælger her.
Brug følgende kommandoer:
git init
git add .
git commit -m "Initial commit"
Tjek resultatet med
git log
Hvilket output giver kommandoen for dit første commit?
Nu har du et repository. Du skal prøve at lave nogle ændringer til filerne, og gemme dem som en række commits med git. Herefter skal du se at ændringerne findes i git-loggen.
Brug denne opskrift:
git add . til at tilføje alle ændrede filer til det næste commit.git status til at se at filerne nu er klar til at komme med i næste commit. Det kaldes at filerne er staged.git commit -m "En tekstbesked". I stedet for “En tekstbesked”, skriv en kort tekst med hvad du har ændret, så andre kan se det i loggen senere.Tjek resultatet med
git log
Du kan navigere op og ned i “git log” med piletasterne, og du kan komme ud igen med knappen “q”.
Prøv punkt 1-4 mindst et par gange mere, og tjek hver gang med git log at de nye ændringer er gemt, og at dine tekstbeskeder optræder i loggen.
Nu skal I hver især have en konto på GitHub.com. Smut ind og opret en ny konto med jeres email. Det er gratis. Brug helst den samme email som i opgave 1.
Næste skridt er at bruge +-knappen på GitHub.com og lave et nyt repository. Der er flere ting der skal udfyldes. Vigtigste pointer:
Tryk herefter på “Create repository” når du har valgt et godt navn. Behold din browser-tab åben og fortsæt til næste opgave.
Når du opretter et repository på GitHub, får du nogle forskellige forslag til hvordan du går videre. Det kan du se i den browser-tab som du har fra sidste opgave.
Forslagene hedder:
Læg mærke til, at forslaget i punkt 1 minder meget om Opgave 1 fra tidligere, så den del er faktisk allerede på plads. Du skal nu lave en kopi af kommandoerne i forslag nr. 2 og udføre dem i terminalen i din lokale git-folder.
Herefter kan du reloade browser-tabben, og se at alle dine filer nu ligger på GitHub.
Herunder forklares kommandoerne nærmere:
Bemærk her, at GitHub for nye bruger har sat hovedbranchen til at hedde main, men mange andre steder bruger man navnet master. Det har ingen praktisk betydning så længe man blot husker at bruge det rigtige navn.
Nu har du et lokalt repository, som har en origin der peger op på GitHub. For at teste hele setuppet, anbefaler jeg at du prøver følgende:
Køre de tre steps igennem et par gange. Prøv herefter om du kan finde listen af ændringer inde på GitHub, svarende til kommandoen git log lokalt.
Til denne opgave skal I vælge en person i jeres studiegruppe, som skal have det overordnede ansvar for jeres fælles repository. Hvis I har lavet opgaver sammen, kunne I dele noget af jeres opgavekode, og senere kan I dele kode i jeres tværfaglige projekt.
Bed personen om at gøre et repository klar med jeres fælles kode, ved at følge opskriften fra tidligere opgaver.
Personen skal nu gå ind på GitHub og sikre, at alle andre gruppemedlemmer har adgang til jeres fælles repository. Dette gøres under “settings - Manage access - Invite a collaborator”.
I andre skal nu se om I får en “invite” og om I efterfølgende kan se indholdet I repository.
Nu skal I alle klone en kopi af det fælles repository så I har det lokalt på jeres PC.
Dette gøres med kommandoen:
git clone <url her>
<url her> skal erstattes med den faktiske URL til jeres fælles repository. Den kan I finde ved at trykke på den grønne “Code” knap inde på GitHub under jeres repository. Her skal i vælge “https” og kopiere URLen.
Når I er færdige med at klone, sidder I forhåbentligt alle sammen og kigger på en kopi af den samme kode.
I skal hver især lave nogle ændringer til koden - prøv at koordinere det så I ikke laver ændringer i det samme - og så skal I lave commits der indeholder jeres ændringer. Følg opskriften fra tidligere opgaver.
I vil opdage af “push” nogle gange fejler, fordi jeres lokale kopi ikke længere har de nyeste commits fra GitHub. Her skal man bruge kommandoen pull:
git pull
Her vil I så nogle gange opdage, at “pull” fejler, da den ikke vil tillade at lokale ændringer, der ikke er committet, bliver overskrevet. Her er idéen at i skal lave en commit på alle jeres ændringer, og så prøve “git pull” igen.
Alternativt kan man gemme “uncommited” ændringer med kommandoen
git stash
Stash bruges ofte som en slags “skraldespand”, men i princippet kan man tage ting fra stash og “poppe” det tilbage i filerne med kommandoen git stash pop. Pop skal forstås ligesom pop() på et array i JavaScript. Jeg anbefaler dog at man committer i stedet for at putte i stash, hvis det er noget man vil gemme.
Andre gange vil man opleve, at “pull” skaber en “merge conflict” og så skal man vælge hvad man vil beholde, og lave et nyt commit når ændringerne er valgt. Læs mere om dette i næste opgave.
Hvis det ikke lykkedes jer på naturligvis vis at få et “merge conflict” i sidste opgave, skal I nu prøve at fremprovokerer et!
Aftal at I alle nu laver ændringer til den samme linje kode i den samme fil, committer, og pusher ændringen op på GitHub. I skal herefter alle lave en git pull. Den der når det først har vundet, og skal nu hjælpe de andre med at løse deres “merge conflicts”.
Aftal hvordan koden skal se ud efter konflikten er løst. Det nemmeste er blot at acceptere ændringer fra den person der kom “først”, da der ellers nemt kan komme konflikter i kølvandet på den første.
Processen for at løse et merge conflict er noget i stil med følgende:
Hvis du står i en situation hvor du er blevet ramt af merge conflict, men du er ligeglad med dine egne seneste ændringer, og bare gerne vil have at din kode er “up-to-date” med det seneste på GitHub, kan du bruge følgende kommando:
git reset --hard origin
Så nulstilles dine lokale commits (i din aktuelle branch) til at være magen til dem på GitHub. Alternativt kan man altid lave en ny “clone”.
Som alternativ til at skrive commit-beskeder med “-m”, kan man også skrive dem direkte i vscode. Dvs. i stedet for at skrive
git commit -m "En tekstbesked"
Kan man i stedet bare skrive
git commit
Det kræver dog at git kender din foretrukne editor (vscode) som blev sat i opgave 1. Her fungerer det sådan, at du får en ny tab i vscode hvor du kan skrive din commit-besked. Herefter skal du gemme indholdet i tabben. Hvis du lukker tabben uden at gemme, bliver commit’en annulleret.
Et godt “cheat sheet” med alle de vigtigste kommandoer kan hentes herunder. Den indeholder også mange kommandoer vi ikke har brugt i denne Workshop, men giver et godt overblik uanset.
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet