-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathgit-og-github.qmd
More file actions
91 lines (55 loc) · 8.43 KB
/
Copy pathgit-og-github.qmd
File metadata and controls
91 lines (55 loc) · 8.43 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
---
title: Hva er Git og GitHub?
date-modified: 08/27/2025
lightbox: true
---
I SSB bruker vi [Git](https://git-scm.com/) til versjonskontroll av koden vår og deler den med andre via [GitHub](https://GitHub.com/). For å mestre disse verktøyene er det viktig å forstå forskjellen mellom Git og GitHub.
::: callout-note
## 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](ssb-project.qmd) 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 GitHub: Bruker og oppsett](github-oppsett.qmd#personal-access-token-pat)**
Eller lurer du på **hvordan du bruker Git-grensesnittet i Jupyter?** Les [denne artikkelen](git-grensesnitt.qmd)!
::: {.callout-tip collapse="true"}
## 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](kvakk.qmd)) har skrevet flere veiledninger på confluence, blant annet om [Git anbefalt arbeidsflyt](https://statistics-norway.atlassian.net/wiki/spaces/BEST/pages/3206283277/Hvordan+er+anbefalt+git+arbeidsflyt), [hvordan man løser en merge conflict](https://statistics-norway.atlassian.net/wiki/spaces/BEST/pages/2951905285/Hvordan+l+se+en+merge-konflikt) og [hvordan man håndterer hemmeligheter og passord i git](https://statistics-norway.atlassian.net/wiki/spaces/BEST/pages/3216703491/Hvordan+h+ndtere+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](https://statistics-norway.atlassian.net/wiki/spaces/BEST/pages/3006889999/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](https://statistics-norway.atlassian.net/wiki/spaces/AS/pages/3708878851/Kom+i+gang+med+Dapla) (statistics-norway.atlassian.net).
Nettsiden [learngitbranching.js.org](https://learngitbranching.js.org/) er også en veldig god ressurs for å forstå konseptene.
:::
## Git {{< fa brands git-alt >}}
### 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](ssb-project.qmd). 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/>.
::: {.callout-note collapse="true"}
## 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](dapla-lab.qmd#git).
### 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 (`.py`og `.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](https://statistics-norway.atlassian.net/wiki/spaces/A700/pages/3567812611/Hvordan+lagre+Jupyter+notebooks+i+rent+tekstformat#Hvordan%3F).
Standardformatet for kobling med Jupytext er [prosent-formatet](https://jupytext.readthedocs.io/en/latest/formats-scripts.html#the-percent-format).
::: {.callout-note collapse="true"}
# 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](https://statistics-norway.atlassian.net/wiki/spaces/Arkitektur/pages/3698458826/ADR0020+-+Lagringsformat+for+Jypyter+Notebooks).
:::
### 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[^1]. 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.
[^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
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 {{< fa brands 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](https://GitHub.com/statisticsnorway). Selv om SSB har en organisasjonskonto på GitHub må alle ansatte opprette sin egen brukerprofil og knytte den mot SSB sin organisasjonskonto.