Anbefalt arbeidsflyt med Git
Å lære seg å bruke git handler om å implementere nye rutiner i arbeidshverdagen. Vi kaller dette for anbefalt arbeidsflyt. Arbeidsflyten er noe man gjennomfører hyppig iløpet av en arbeidsdag om man jobber med kode. Vi beskriver derfor anbefalt git arbeidsflyt fra man begynner på en ny oppgave til den er avsluttet og merget til main.
Denne siden er en inspirert av Beste Praksis sin confluence-artikkel Hvordan er Git anbefalt arbeidsflyt?.
Les vår artikkel om Git og GitHub. Der kan du lære hva verktøyene er og hvorfor vi bruker de i SSB.
Arbeidsflyt
1. Oppdater ditt lokale repo
1.1 Sørg for at repoet ikke har ulagrede endringer
terminal
git status # Viser hvilke filer som er endret, nye eller klare for commit
Vil du lagre endringene gjør du som beskrevet i punkt 4. Hvis ikke kjører du følgende:
terminal
git reset --hard HEAD # forkaster endringer
1.2 Oppdater lokal versjon av main
terminal
git switch main # bytt til main
git pull # oppdaterer
2. Lag ny gren (branch)
I vårt eksempel skal vi omstrukturere denne delen av manualen. Vi kaller derfor grenen omstrukturere-git-github
terminal
git switch -c omstrukturere-git-github # -c står for create
3. Gjør endringer i repoet/koden
4. Lagre kode og oppdatere repoet på GitHub
Dette er hoveddelen av arbeidsflyten og en prosess man vil gjenta flere ganger før man er ferdig med en gren.
terminal
git status # Viser hvilke filer som er endret, nye eller klare for commit
git add <filnavn> # For alle filer du vil ha med i committen
git commit -m"<tekst som beksriver endringer>"
git push # Sender endringene til GitHub
git add .
legger til alle filer! Da slipper man å skrive hvert filnavn.
Man kan også legge til alt nytt innhold i en mappe ved å skrive git add <mappenavn>
.
Om du vil legge til alle filer av en filtype kan man skrive git add *<filtype>
. For eksempel: git add *.py
.
5. Gjenta steg 3 og 4 til oppgaven er ferdig
6. Sjekk for merge-konflikt: Merge inn endringer fra main til din gren
Dette gjør vi fordi det er lettere å løse mergekonflikter lokalt enn på GitHub. Sjekk først at du har en ‘ren’ git status slik vist i punkt 1.1.
terminal
git fetch # Synkroniserer origin-biten av ditt lokale repo med github
git merge origin/main # evt. origin/master om hovedgrena heter master
git push
Om du får en merge-konflikt løser du dette slik det er beskrevet i siste del av denne artikkelen: Hvordan løse en merge-konflikt.
7. Opprett en pull request på GitHub
7.1 Finn repoet på GitHub
7.2 Opprett ny pull request
Har du nylig pushet kan du trykke på Compare & pull request der den lilla pilen viser. Eventuelt kan man trykke på pull requets slik den grønne boblen viser.
7.3 Beskriv endringene
7.4 Be en kollega om se over
For eksempel ved å bruke GitHub sin request review funksjon. Eller sende melding på teams
7.5 Merge og slette gren
Når en kollega har godkjent endringene vil merge-knappen bli grønn slik bildet nedenfor viser.
Etter å ha merget vil man få muligheten til å slette grenen enkelt ved å trykke på den grå knappen siste figur viser.
Arbeidsflyt og repo illustrert
Hvordan løse en merge-konflikt
Hvis to personer har endret samme linje i en fil vet ikke Git hvilken av endringene den skal velge. Dette kalles en merge-konflikt. I vårt tilfelle vil dette skje om endringene har skjedd i main etter at vi lagde grenen vår.
Om en slik konflikt oppstår må man manuelt velge hvilken versjon man ønsker. Følg denne veiledningen (confluence) for å løse en merge-konflikt.