Git og GitHub

I SSB bruker vi Git til versjonskontroll av koden vår og deler den med andre via GitHub. For å mestre disse verktøyene er det viktig å forstå forskjellen mellom Git og GitHub.

Git vs. GitHub: Kort fortalt

Git er et verktøy installert på din lokale maskin som sporer endringer i koden din.
GitHub er en skybasert plattform som fungerer som et felles lagringssystem der du kan dele og samarbeide med andre om kode.

Git og GitHub er viktige verktøy for å sikre at produksjonssystemene våre er trygge og reproduserbare. De gjør det enkelt å spore endringer og gjennomgå eller godkjenne hverandres bidrag.

I denne artikkelen ser vi nærmere på Git og GitHub og hvordan de er implementert i SSB. Selv om ssb-project gjør det lettere å forholde seg til Git og GitHub vil vi dette kapittelet forklare nærmere hvordan det funker uten dette hjelpemiddelet.

Er du her for å opprette Personal Access Token? Les siste del av artikkelen!

Les videre med interne ressurser

Det finnes mange gode ressurser på huset om versjonshåndtering i tillegg til denne artikkelen. Gruppen Kvalitet i Kode og Koding (KVAKK) har skrevet flere veiledninger på confluence, blant annet om Git anbefalt arbeidsflyt, hvordan man løser en merge conflict og hvordan man håndterer hemmeligheter og passord i git. Se hele katalogen til KVAKK om Git og GitHub ved å gå inn på deres confluence-område: Versjonskontroll med Git.

I tillegg har A200 sitt støtteteam skrevet om hva man bør lære seg og hvordan man går frem for å lære i confluence-dokumentet Kom i gang med Dapla (statistics-norway.atlassian.net).

Nettsiden learngitbranching.js.org er også en veldig god ressurs for å forstå konseptene.

Git

Hva er Git?

Git er en programvare for distribuert versjonshåndtering av filer:

• Git tar vare på historien til koden din
• Alle som jobber med koden har en kopi av koden hos seg selv (distribuert)

Når man ønsker å dele kode med andre laster man det opp til et felles kodelager på GitHub kalt repository (repo). Vanligvis versjonshåndteres rene tekstfiler, men git kan også versjonshåndtere bilder og PDFer.

Git er installert på maskinen du jobber på og brukes fra terminalen. Det finnes pek-og-klikk versjoner av Git, blant annet i Jupyterlab og RStudio, men noen situasjoner vil bare kunne løses i terminalen.

I SSB anbefaler vi at du starter et nytt Git-prosjekt ved å benytte ssb-project. Da vil du ikke bare aktivere Git, men du kan også få implementert en del andre gode praksiser for å holde koden din ryddig, oversiktlig og sikker.

Les mer om Git på https://git-scm.com/.

Git i praksis: Kort fortalt

Man aktiverer Git på en mappe i filsystemet sitt med kommandoen git init når man står i mappen som skal versjonshånderes. Da vil Git versjonshåndtere alle filer som er i den mappen og i eventuelle undermapper. Når du så gjør endringer på en fil i mappen, vil Git registrere endringer. Ønsker du at endringen skal bli et punkt i historikken til prosjektet, så må du først legge til filen i Git med kommandoen git add filnavn. Når du har gjort dette, så kan du lagre endringen med kommandoen git commit -m "Din melding her". Når du har gjort dette, så vil endringen være lagret i Git. Når du har gjort mange endringer, så kan du sende endringene til GitHub med kommandoen git push. Når du har gjort dette, så vil endringene være synlige for alle som har tilgang til GitHub-prosjektet.

Oppsett av Git/GitHub på Dapla Lab

Man kan lagre GitHub-brukernavn og PAT i Dapla Lab sine instillinger. Da vil de hentes automatisk hver gang man Git/Dapla Lab trenger det. Vi har skrevet en egen del om det i artikkelen vår om Dapla Lab.

Git, notebooks og filformat: Jupytext

Når man versjonshåndterer bør man ta hensyn til hvilket filformat man lagrer kode i. Versjonshåndtering av notebooks (.ipynb) er ikke anbefalt siden filene inneholder mer enn bare tekst. De inneholder metadata og kode er delt inn i celler. Det gjør de vanskelig for mennesker å lese og dermed kontrollere/versjonshåndtere. I tillegg risikerer man å dytte opp data hvis man versjonshåndterer notebooks da notebooks kan lagre output. Tekstfiler (.pyog .R) er derimot enklere og tryggere å versjonshåndtere.

Derfor bruker vi et verktøy som heter Jupytext. Jupytext synkroniserer notebooks med en tilsvarende tekstfil. Det lar oss skrive kode i notebooks mens programmene våre lagres og versjonshåndteres som tekstfiler. Det gir oss brukervennligheten til notebooks uten krøllet som oppstår når man skal versjonshåndtere de. Det er derfor vanlig å ha linjen *.ipynb i .gitignore-filen: da vil alle notebooks ignoreres av Git, og den vil bare forholde seg til de synkroniserte tekstfilene (altså tilsvarende .py eller .R-fil). Les om hvordan man implementerer og bruker Jupytext på IT-avdelingen sin confluence-side.

Standardformatet for kobling med Jupytext er prosent-formatet.

Bruk av Jupytext et vedtak fra IT

Bruk av jupytext er en Architecture Decision Record (ADR) - altså et vedtak fra IT. Les mer om ADR0020 på Confluence.

Vanlige Git-operasjoner

I git er det noen operasjoner som er så vanlige at alle som jobber med kode i SSB bør kjenne dem:

• git status for å se hvilke endringer Git har oppdaget
• git add <filnavn> for å fortelle Git at endringene skal lagres
• git commit -m "Din melding her" for å gjøre endringene om til et punkt i historien til koden din (flere filer kan samles under en commit)
• git push for å sende endringene opp til GitHub

Når man utvikler kode gjør man det fra såkalte branches¹. Hvis vi tenker oss at din eksisterende kodebase er stammen på et tre (ofte kalt master eller main) legger Git opp til at man gjør endringer på denne koden via grener av treet. Med andre ord holder vi stammen (main) urørt helt til vi vet at endringen fungerer som den skal. Til slutt merger vi arbeidsgrenen inn i main. Vi kan opprette en ny branch og gå inn i den ved å skrive git switch -c <branch navn>. Da står du i en branch og kan bruke kommandoer som git add og git commit som vist tidligere.

Når man er fornøyd med endringene i en branch, så vil man pushe den opp til GitHub, slik at en kollega kan vurdere om den skal merges inn i main. Denne vurderingen gjøres i en pull request. Dermed gjøres selve mergen i GitHub-grensenittet. Vi skal se nærmere på GitHub i neste kapittel.

GitHub

GitHub er et nettsted som bl.a. fungerer som vårt felles mappesystem for deling av kode. SSB har sin egen organisasjonskonto med navn statisticsnorway. Selv om SSB har en organisasjonskonto på GitHub må alle ansatte opprette sin egen brukerprofil og knytte den mot SSB sin organisasjonskonto.

Opprett GitHub-bruker

For å lage repoer og bidra til eksisterende repoer må man ha en GitHub-bruker.

SSB har valgt å ikke sette opp SSB-brukerne til de ansatte som GitHub-brukere. En viktig årsak er at en GitHub-konto ofte regnes som en del av den ansattes CV. For de som aldri har brukt GitHub før kan det virke fremmed, men det er nok en fordel på sikt når alle blir godt kjent med denne arbeidsformen.

Slik gjør du det:

1. Gå til https://GitHub.com/
2. Trykk Sign up øverst i høyre hjørne
3. I dialogboksen som åpnes, se Figur 1, skriver du inn din e-postkonto og lager et passord. Dette trenger ikke være din SSB-bruker og e-post. Hvis du bruker en en personlig e-postkonto er det viktig at du tydeliggjør hvem du er så kollegaer vet at du jobber i SSB når de ser aktivitet fra deg.

Figur 1: Dialogboks for opprettelse av GitHub-bruker.

Du har nå laget en egen GitHub-bruker. I neste steg skal vi knytte denne kontoen til din SSB-bruker.

To-faktor autentisering

Hvis du har fullført forrige steg har du nå en GitHub-konto. Hvis du står på din profil-side ser den ut som i Figur 2.

Figur 2: Et eksempel på hjemmeområdet til en GitHub-bruker

Det neste vi må gjøre er å aktivere 2-faktor autentisering, siden det er dette som benyttes i SSB. Hvis du står på siden i bildet over, så gjør du følgende for å aktivere 2-faktor autentisering mot GitHub:

1. Trykk på den lille pilen øverst til høyre og velg Settings(se Figur 3).

2. Deretter velger du Password and authentification i menyen til venstre.

3. Under Two-factor authentication trykker du på Enable.

Figur 3: Åpne settings for din GitHub-bruker.

4. Figur 4 viser dialogboksen som vises. Velg Enable two-factor authentification.

Figur 4: Dialogboks som åpnes når 2FA skrus på første gang.

5. Figur 5 viser dialogboksen som vises for å velge hvordan man skal autentisere seg. Her anbefales det å velge Set up using an app, slik at du kan bruke Microsoft Authenticator-appen på din mobil.

Figur 5: Dialogboks for å velge hvordan man skal autentisere seg med 2FA.

Figur 6 viser QR-koden som vises. Denne skal vi bruke i neste steg.

Figur 6: QR-kode som skannes av Microsoft Authenticator.

6. Strekkoden over skal skannes i din Microsoft Authenticator-app på mobilen, som vist i Figur 7. Åpne appen, trykk på Bekreftede ID-er, og til slutt trykk på Skann QR-kode. Deretter skanner du QR-koden fra punkt 5.

7. Når koden er skannet har du fått opp følgende bilde på appens hovedside (se bilde til høyre). Skriv inn den 6-siffer koden på GitHub-siden med QR-koden.

8. Til slutt lagrer du Recovery-codes et trygt sted som bare du har tilgang til.

Figur 7: Mobilappen Microsoft authenticator

Nå har vi aktivert 2-faktor autentisering for GitHub og er klare til å knytte vår personlige konto til vår SSB-bruker på SSBs “GitHub organisation” statisticsnorway.

Koble deg til SSB

I forrige steg aktiverte vi 2-faktor autentisering for GitHub. Det neste vi må gjøre er å koble oss til Single Sign On (SSO) for SSB sin organisasjon på GitHub:

1. Trykk på lenken https://GitHub.com/orgs/statisticsnorway/sso
2. I dialogboksen som dukker opp trykker du på Continue, slik som vist i Figur 8.

Figur 8: Single Sign on (SSO) for SSB sin organisasjon på GitHub

Når du har gjennomført dette så har du tilgang til statisticsnorway på GitHub. Går du inn på denne lenken så skal du nå kunne lese både Public, Private og Internal repoer, slik som vist i Figur 9.

Figur 9: Medlemsvisning for SSB sin GitHub-organisasjon.

Personal Access Token (PAT)

Når vi skal jobbe med SSB-kode som ligger lagret hos statistcsnorway på GitHub, så må vi autentisere oss. Måten vi gjøre det på er ved å generere et Personal Access Token (ofte forkortet PAT) som vi oppgir når vi vil hente eller oppdatere kode på GitHub. Da sender vi med PAT for å autentisere oss for GitHub.

Opprette PAT

For å lage en PAT som er godkjent mot statisticsnorway gjør man følgende:

1. Gå til din profilside på GitHub og åpne Settings slik som ble vist Seksjon 2.2.

2. Velg Developer Settings i menyen til venstre.

3. I menyen til venstre velger du Personal Access Token, og deretter Tokens (classic).

4. Velg Generate new token og deretter Generate new token (classic).

5. Under Note kan du gi PAT’en et navn. Velg et navn som er intuitivt for deg. Hvis du skal bruke PAT til å jobbe mot Dapla, så ville jeg ganske enkelt kalt den dapla. Hvis du skal bruke den mot bakkemiljøet ville jeg kalt den prodsone eller noe annet som gjør det lett for det skjønne innholdet i ettertid.

6. Under Expiration velger du hvor lang tid som skal gå før PAT blir ugyldig. Dette er en avvening mellom sikkerhet og hva som er praktisk. Det anbefales at du velger 365 dager. Når PAT utløper må du gjenta stegene i dette kapittelet.

7. Under Select scopes velger du repo og workflow slik som vist i Figur 10.

Figur 10: Gi token et kort og beskrivende navn

8. Trykk på Generate token nederst på siden og du får noe lignende det du ser i Figur 11.

Figur 11: Token som ble generert.

9. Kopier deretter PAT til en midlertidig fil. Grunnen er at du aldri vil se det igjen her etter at vi har gjennomført neste steg.

10. Deretter trykker du på Configure SSO og velger Authorize ved siden statisticsnorway, slik som vist i Figur 12. Svar deretter på spørsmålene som dukker opp.

Figur 12: Autorisering av Token mot SSBs GiHub-organisasjon.

Vi har nå opprettet en PAT som er godkjent for bruk mot SSB sin kode på GitHub. Det betyr at hvis vi vil jobbe med Git på SSB sine maskiner i sky eller på bakken, så må vi sendte med dette tokenet for å få lov til å jobbe med koden som ligger på statisticsnorway på GitHub.

Lagre PAT i Dapla Lab

Anta at min personlige GitHub-bruker er SSB-Chad og at min Personal Access Token er a13bc12. Da kan jeg gjøre følgende for å lagre det i Dapla Lab:

1. Logg inn på https://lab.dapla.ssb.no
2. Trykk på ‘My account’
3. Naviger til Git-fanen
4. Skriv inn brukernavn (f.eks SSB-Chad) under Username for Git
5. Skriv inn e-posten som er koblet opp mot Git
6. Lim inn token (f.eks a13bc12) der det står ‘Git Forge Personal Access Token’ vist i Figur 13

Figur 13: DaplaLab My account: lagre PAT

Fotnoter

1. Branches kan oversettes til grener på norsk. Men i denne boken velger vi å bruke det engelske ordet branches. Grunnen er at det erfaringsmessig er lettere forholde seg til det engelske ordet når man skal søke etter informasjon i annen dokumentasjon