"/Users/solfrid/opt/anaconda3/lib/python3.7/site-packages/IPython/core/display.py:717: UserWarning: Consider using IPython.display.IFrame instead\n",
" warnings.warn(\"Consider using IPython.display.IFrame instead\")\n"
]
},
{
"data": {
"text/html": [
...
...
@@ -560,7 +552,7 @@
"<IPython.core.display.HTML object>"
]
},
"execution_count": 1,
"execution_count": 12,
"metadata": {},
"output_type": "execute_result"
}
...
...
@@ -767,13 +759,15 @@
"\n",
"Tar utgangspunkt i at det er en \"Nedlastninger\"-mappe `filstruktur_eksempel`-mappa har havna i etter nedlasting.\n",
"\n",
"Følgende kommandoer skrives inn i terminalen:\n",
"For å navigere deg til `filstruktur_eksempel` i kommandolinjen din, må du først navigere deg til `Nedlastninger` ved å skrive kommandoen\n",
"\n",
"`cd Nedlastninger`\n",
"\n",
"og deretter skrive\n",
"`cd filstruktur_eksempel`\n",
"i kommandolinjen for å komme deg til `filstruktur_eksempel` til slutt. \n",
"\n",
"For å skrive ut innholdet, skriv\n",
"For å skrive ut innholdet i mappen, skriver du\n",
"\n",
"`ls`"
]
...
...
@@ -815,14 +809,15 @@
"Du kan enten skrive\n",
"\n",
"`cd itgk/forelesning/min_kode`\n",
"\n",
"Eller gå ned en og en mappe\n",
"for å navigere deg til mappen i et steg, eller gå ned tre nivåer i tre ulike steg ved å skrive følgende:\n",
"\n",
"`cd itgk` \n",
",deretter tryker du enter\n",
"\n",
"`cd forelesning`\n",
",trykk enter\n",
"\n",
"`cd min_kode`\n",
"`cd min_kode` , og trykk enter igjen. \n",
"\n",
"----\n",
"For å skrive ut innholdet til fila\n",
...
...
@@ -875,8 +870,11 @@
"source": [
"**Løsningsforslag 3**\n",
"\n",
"Kommandoen\n",
"`cd ../../../BM1/forelesning`\n",
"tar deg først tre nivåer opp til `filstruktur_eksempel` og ned til `BM1` og undermappen `forelesning` som ligger i mappen, `BM1`.\n",
"\n",
"Du kan printe innholdet i `forelesning` med kommandoen\n",
"`ls`"
]
},
...
...
@@ -894,7 +892,7 @@
"source": [
"**Oppgave 4**\n",
"\n",
"Nå står du i forelesningsmappa. Bruk `mkdir` til å lage en ny mappe i BM1 (du må først navigere til denne mappa) som heter `ovinger`."
"Nå står du i mappen, `forelesning`. Bruk `mkdir` til å lage en ny mappe i BM1 (du må først navigere til denne mappa) og navngi denne undermappen som `ovinger_bm1`."
]
},
{
...
...
@@ -910,12 +908,14 @@
"source": [
"**Løsningsforslag 4**\n",
"\n",
"`cd ../`\n",
"Først må du navigere opp til mappen, `BM1` ved å skrive følgende kommando:\n",
"`cd ..`\n",
"\n",
"`mkdir ovinger`\n",
"Nå står du i mappen, `BM1` og kan lage undermappen `ovinger_bm1` ved å skrive:\n",
"`mkdir ovinger_bm1`\n",
"\n",
"Eller i ett:\n",
"`mkdir ../ovinger`"
"Evt. kan du både gå til mappen, BM1 og lage en undermappe der i ett steg ved å skrive følgende kommando:\n",
"`mkdir ../ovinger_bm1`"
]
},
{
...
...
@@ -2216,7 +2216,9 @@
"\n",
" \n",
"\n",
"Vi skal se på GitKraken som et eksempel i guiden under, som per juli 2020 har pro versjonen gratis for studenter som registrerer seg på GitHub som student. GitKraken fungerer for hvilken som helst operativsystem. Merk at dette er et kommersielt program, og om du velger å bruke det er helt valgfritt. Det finnes også andre gratis open-source løsninger, en oversikt over disse finner du ved å trykke [her](https://acodez.in/git-gui-clients/). Prinsippet er ofte det samme, fordi de alle er basert på Git. Hvilket program som er best for deg vil avhenge av operativsystem. [Denne linken her](https://acodez.in/git-gui-clients/) gir en beskrivelse av de opplistede GUI programmene for Git. \n",
"Vi skal se på GitKraken som et eksempel i guiden under, som per juli 2020 har pro versjonen gratis for studenter som registrerer seg på GitHub som student. GitKraken fungerer for hvilken som helst operativsystem. Merk at dette er et kommersielt program, og om du velger å bruke det er helt valgfritt. Det finnes også andre gratis open-source løsninger, en liste over forslag til programmer som tilbyr GUI for Git og beskrivelse av disse finner du f.eks [her](https://acodez.in/git-gui-clients/). Prinsippet er ofte det samme, fordi de alle er basert på Git. Hvilket program som er best for deg vil avhenge av operativsystem. \n",
"\n",
"Det er også verdt å nevne at noen store IDEer (Integrated Development Environment, på norsk: grafiske utviklingsgrensesnitt) har Git integrert slik at du kan bruke Git direkte i IDEen du skriver kode i direkte. Eksempler på disse er Pycharm og IntelliJ. Det anbefales at du setter deg inn i hvordan du bruker Git i den IDEen du jobber i. \n",
"\n",
"Om du ønsker å følge videoen under og komme i gang med GitKraken, må du først lage en GitHub bruker som student hvis du ikke har gjort det enda. Trykk [her](https://education.github.com/students) og videre på knappen 'Get benefits for students'. Sørg for å bruke NTNU-mailen din når du registerer deg som student. \n",
"\n",
...
...
%% Cell type:markdown id: tags:
<tablestyle="font-size:15px; margin-left:0px">
<tr>
<td><ahref="../JN0.ipynb">Tilbake til oversikt over notebooks</td>
</tr>
</table>
%% Cell type:markdown id: tags:
<h1> Bruk av Git for versjonskontroll og samarbeid</h1>
%% Cell type:markdown id: tags:
**Forventet kunnskap:**
- Ingen
%% Cell type:markdown id: tags:
**Læringsmål:**
- Forstå hva et versjonskontroll er og hvorfor det er nyttig
- Ha kjennskap til hva Git er:
- Forstå hva "working area", "staging area" og "repository" er i Git
- Forstå hva en "commit" er
- Forstå hva konseptene "branch" og "merge" er
- Kunne bruke kommandolinjen på datamaskinen til å navigere til en ønsket mappe med `cd`, skrive ut hva mappen inneholder med `ls`, skrive ut en filsti med `pwd` og kunne lage en ny mappe med `mkdir`.
- Vite hvordan man lager et nytt "repository" med `git init`.
- Vite hvordan man "stager" endringer som blir gjort på ulike filer i en mappe.
- Vite hvordan man "commiter" en endring.
- Bruke `git status` for å få oversikt over tilstanden til et prosjekt.
- Kunne bruke kommandoen, `git branch` til å både lage en branch og få oversikt over alle branches (grener) som finnes.
- Kunne bruke kommandoen, `git checkout` for å bytte mellom ulike branches (grener).
- Kunne slå sammen "branches" med kommandoen `git merge`.
- Forstå hvorfor "merge conflict" skjer, og hvordan man kan løse dette.
- Kunne trekke tilbake en "commit", med `git reset` og angre en "commit" med `git revert`.
- Kunne bruke `git log` til å få oversikt over en "commithistorikk".
- Vite at du kan bruke `git diff` til å sammenligne filer, branches (grener) og "commits".
- Vite at du kan bruke `git clean` for slette "untracked" (usporede) filer under "working area".
- Få kjennskap til hvordan du får Git til å ignorere uønskede filer ved å lage en .gitignore fil og aktivere denne.
- Forstå forskjellen på lokal versjonskontroll og "remote" versjonskontroll.
- Vite hvordan man kan lage en remote repo på GitHub som et eksempel.
- Forstå hvordan man kan samarbeide med andre via "remote repositories".
- Hvordan lagre en "remote repository" lokalt på din datamaskin med kloning (*eng: cloning*).
- Bruke `git push` for å publisere endringer til en remote repo og `git pull` for å hente endringer fra en remote repo.
- Vite om andre programmer for å bruke Git utenom kommandolinjen som tilbyr et brukergrensesnitt.
%% Cell type:markdown id: tags:
I fremtiden kan det hende du skal skrive større programmer på f.eks. noen hundre kodelinjer, eller skal samarbeide med andre på et kodeprosjekt. Det er da versjonskontroll blir viktig. I denne notebooken skal vi se nærmere på hva en versjonskontroll er og hvorfor vi bruker versjonskontroll. Vi skal videre se nøyere på det distribuerte versjonskontrollssystemet, Git og hvordan man bruker Git i en arbeidsflyt og et samarbeid.
%% Cell type:markdown id: tags:
# Introduksjon til versjonskontroll, Git og installasjon
<aid = 'introduksjon_git'></a>
%% Cell type:markdown id: tags:
## Hva er versjonskontroll og hvorfor trenger vi det?
%% Cell type:markdown id: tags:
Når du skriver et program med en del kodefiler og gjør endringer på de ved f.eks. å legge til kode, endrer kode, eller slette kode, kan det være greit å holde styr på hver endring du gjør på koden din. Tidligere er du kanskje vant med å lagre nye kopier av koden din på PC-en din, men du er redd for å skrive over en tidligere versjon så du ender opp med ulike filer av koden din med ulike versjoner? Dette er ikke en optimal arbeidsflyt når du jobber med endringer. En ryddigere løsning kan være å bruke noe som heter versjonskontroll på filene dine i stedet. Versjonskontroll er et verktøy som sørger for å gi deg som bruker en oversikt over alle endringene du har gjort på en eller flere filer.
Se for deg at du har en kode som fungerer helt fint, men du ønsker å prøve deg frem litt med noen endringer, og koden ender opp med å slutte å oppføre seg korrekt. Ved å bruke en versjonskontroll, kan du da gå tilbake til koden slik den tidligere var. Du kan derfor angre endringene dine ved å bruke versjonskontroll, på samme måte som du kan angre endringene dine når du skriver i Word, Google Docs, Pages og andre tekstfilprogrammer. Du kan også rulle tilbake en endring du har angret på tidligere for å få tilbake endringen din som du fjernet med angring. Et versjonskontroll-verktøy er altså et verktøy som gjør det enklere å gå tilbake til endringene dine uten å måtte lagre flere kopier av koden din på PC-en, noe du antageligvis ville gjort foruten en versjonskontroll.
Versjonskontroll forenkler også samarbeid på de samme filene. Når du bruker versjonskontroll, er det enklere å kombinere endringer som flere har gjort. Derfor er det anbefalt å bruke dette når dere er flere som jobber på de samme filene. Det gir alle gruppemedlemmene en ryddig oversikt over endringer som har blitt gjort og er i tillegg et verktøy som hjelper til å sammenstille endringer alle gruppemedlemmene gjør.
Bruk av versjonskontroll er noe du mest sannsynlig vil støte på i arbeidslivet når du samarbeider med flere om et felles prosjekt og du vil også dra nytte av å bruke dette når du samarbeider med andre medstudenter i øvinger/prosjekter under studiet. I et samarbeid, skal flere helst jobbe på samme kodebase men lage egne versjoner av denne. Og endringene skal slåes sammen. Versjonskontroll gjør det enklere å holde styr på konflikter som kan oppstå av en slik sammenslåing i et samarbeid. I tillegg kan det hende at endring av krav fører til at man må gå tilbake til eldre versjon av koden. Dette hjelper versjonskontroll deg med å oppfylle også.
Det finnes flere ulike systemer for versjonskontroll. Vi skal se på ett av de mest kjente, som heter Git. For å komme i gang må du installere Git. Prosessen er forskjellig på Mac, Windows og Linux, så derfor er det tre dropdown menyer [her](#git_installasjon). Følg den som passer for ditt operativsystem.
%% Cell type:markdown id: tags:
## Hva er Git?
%% Cell type:markdown id: tags:
Git er et program som tilbyr et *distribuert versjonskontroll system*. Som nevnt i forrige seksjon, er et versjonskontrollsystem et verktøy som holder styr på filene dine som du velger å spore. Et versjonskontrollsystem gjør det mulig å lagre endringer og spore endringer i disse filene. Det er kjerneoppgaven til Git. Måten Git sporer endringene på, er at programmet lager en tidslinje av endringer som har blitt gjort på et arbeid inkludert beskrivende sjekkpunkter for hver versjon/endring av koden. Bildet under visualiserer et eksempel på en slik tidslinje. Et arbeid kan være en mappe som består av mange kodefiler. Disse kan være ulike filtyper, som f.eks. Javafiler, Pythonfiler og Jupyter Notebook filer.
La oss si at du har en mappe på PC-en din som inneholder Python-filene du har laget for hver øving. Med Git kan du holde styr på endringer du gjør i disse filene og lage en tidslinje med sjekkpunkter slik at det er mulig å gå tilbake til eldre versjoner av filene og nyeste versjonen av filene. Dette gjør det mulig å bruke Git som et "undo" (angre) og "redo" (rulle tilbake angring) verktøy for endringene du gjør på arbeidet, der du kan enten angre (undo) en endring eller rulle tilbake angringen (redo). Det er dette som menes med at Git er et versjonskontroll system. Det hjelper deg å kontrollere alle de ulike versjonene av et arbeid.
Bildet under er en visualisering av endringer som har blitt gjort i en mappe lokalt på en PC. I denne mappen har det blitt lagt til filer. Visualiseringen består av en tidslinje av ulike versjoner av prosjektet, og tilhørende beskrivende meldinger som forklarer hvilke endringer det er som har blitt gjort. Denne visualiseringen har blitt laget i et program som kalles GitKraken og er ment å illustrere konseptet. GitKraken kommer til å bli introdusert i seksjonen, [Bruke GUI med Git](#git_gui) . Du trenger foreløpig ikke å tenke på hvordan GitKraken fungerer.
<imgsrc = 'img/git_tre.png'width = 800px>
%% Cell type:markdown id: tags:
Bildet under viser et skjermbilde av mappen og filene som har blitt lagt til der.
<imgsrc = 'img/mappestruktur.png'width = 800>
%% Cell type:markdown id: tags:
Det største bruksområdet for Git, er å bruke det som et verktøy til å samarbeide på et felles arbeid (en mappe med filer i). Git gjør det enklere å legge til endringer og hente ut endringer som andre har gjort i det arbeidet som er felles. Det er mulig å bruke Git når man samarbeider på et felles prosjekt (en samling av kodefiler) ved å publisere prosjektet og de ulike versjonene av det på en server. Da skylagrer Git de endringene som gruppemedlemmer gjør på prosjektet til en annen tjeneste utenom den lokale PC-en til de som samarbeider. På den måten kan alle få tilgang til det felles prosjektet med den nyeste versjonen av koden. Det er dette man bruker en *remote repository* til. Dette konseptet forklarer i mer detaljer i seksjonen, [Bruk Git i et samarbeid](#git_samarbeid).
I tillegg ble det nevnt at Git er et *distribuert* versjonskontroll system. At Git er i tillegg et distribuert versjonskontroll system, betyr at Git muliggjør lagring av en kopi av et felles arbeid lokalt på alle deltagerne sin PC. Mer om dette kommer i seksjonen, [Bruke Git i samarbeid](#git_samarbeid)
%% Cell type:markdown id: tags:
## Hvordan fungerer Git?
%% Cell type:markdown id: tags:
Vi antar nå at du har kodefiler i en mappestruktur som du skal gjøre noen endringer på og samarbeide med andre på. Denne samlingen av kodefiler kaller vi for et prosjekt videre. Her er et eksempel på et prosjekt som du kan bruke Git til:
<imgsrc='img/mappestruktur.png'width=800px>
%% Cell type:markdown id: tags:
Når du starter Git for første gang i prosjektet ditt, lager programmet et *repository* for filene dine. Da lages det en mappe i prosjektet ditt som heter .git/ når du startet Git. Merk at denne mappen ikke vil være synlig i filutforsker (Windows)/Finder(Mac) når du starter Git.
Et repository, som vi forkorter som et repo, kan du tenke på som en lagringsplass for både filene dine og endringene på de, og det er filene dine som ligger i Git repoet som faktisk blir sporet av Git. Derfor må selve filene dine legges til i repoet for at Git skal kjenne de igjen og dermed spore endringene som blir gjort på dem. Når filene dine er lagt til i Git repoet, vil Git lage en tidslinje med ulike versjoner av filene dine som inkluderer ulike endringer som har blitt gjort på dem over tid. Du som bruker kommer ikke til å interagere direkte med Git repoet (.git mappen), så det viktigste er bare å ha en overordnet forståelse av hva et Git repo er.
Prosessen med å legge til filene dine og endringene på dem i Git repoet skal nå bli introdusert.
Endringer du gjør på filene dine i et prosjekt der du bruker Git som versjonskontroll, kan havne i tre ulike faser. Når du legger til filer, sletter filer eller endrer på filer i prosjektet ditt, havner disse endringene først i noe som kalles for *working area*. Du kan tenke på working area som en plass der endringene til prosjektet befinner seg i, men som foreløpig er en kladd. Endringene som befinner seg i working area, venter på å bli klargjort til godkjenning. På dette stadiet blir ikke endringene lagret i Git systemet.
Før du kan lagre endringene som befinner seg i working area i Git repoet, må filene gjennom en fase til, kalt *staging area*. Som vist i bildet under, er det en prosess som går fra working area til staging area, og denne prosessen kalles for staging. Når du stager endringene dine, betyr dette at du klargjør disse til lagring i Git repoet.
Når filene dine er i staging area, venter de på at du lagrer endringene i Git repoet (evt. sletter endringene siden du på dette stadiet kan angre endringene dine også). Når filene er staget, kan du endelig lagre endringene ved å *commite* og de vil til slutt havne i Git repoet til prosjektet ditt. Du må altså stage endringene dine før du kan commite endringene dine. En commit lager et øyeblikksbilde av endringen din i Git repoet. Når du commiter endringene dine, begynner Git å lage en tidslinje av endringene dine som det ble nevnt lenger oppe. Det er først når du har gjort en commit på en endring i prosjektet at du kan gå tilbake til denne ved en senere anledning om det skulle trenges. Neste gang du gjør endringer på filene som nå ligger i Git repoet ditt, vil de havne først i working area der du må stage dem igjen før du kan commite dem slik at de lagres i repoet. Og slik fortsetter det i en "sykel" hver gang du gjør endringer i prosjektet ditt.
En fil vil være ukjent og regnes som *untracked* (uspored) av Git før du gjør din aller første commit på den, men etter den første commiten, regnes den som "kjent" for Git og da karakteriseres den ikke som "untracked" lenger. Det er da tidslinjen til de fremtidige versjonene av filen din starter.
Bildet under gir en visuell fremstilling av konseptene, staging og commiting. Boksene viser de ulike områdene endringene dine kan gå gjennom og pilene viser prosessen som skal til for å komme seg fra et område til neste.
Når du først har fått på plass et repository, kan du gjøre endringer på et prosjekt som følger en egen tidslinje i noe som kalles for en *branch* (gren). En branch er en egen tidslinje som prosjektet ditt følger, og kan også tenkes på som et eget "arbeidsmiljø" der du kan gjøre endringer på prosjektet ditt uten å skrive over endringer som har blitt gjort i en annen branch (som følger et annet tidsforløp). Det vil si at når du har gjort endringer på en branch og lagret disse endringen mens du var i branchen din, vil disse endringene ikke være synlig om du bytter til en annen branch. Altså er det mulig å lagre flere tidslinjer som følger en trestruktur i Git repoet til et prosjektet. La oss se nøye på bilde fra forrige seksjon igjen:
<imgsrc = 'img/git_branch.png'width = 800px>
Den røde elipsen markerer de to branchene som finnes i repositoryen i dette eksempelet. Her er det altså en branch som heter master og en som heter oving1. Mer detaljer om branch kommer i seksjonen [her](#om_branch_og_merge)
%% Cell type:markdown id: tags:
## Installer Git
<aid = "git_installasjon"></a>
%% Cell type:markdown id: tags:
### Linux
%% Cell type:markdown id: tags:
Git pakker er tilgjengelig via apt, yum og dnf. Last ned git pakken i din kommandolinje. Hvis du bruker f.eks Ubuntu, skriver du `sudo apt-get update` for å oppdatere apt og deretter
`sudo apt-get install git` for å laste ned Git.
%% Cell type:markdown id: tags:
### Windows
%% Cell type:markdown id: tags:
<h4> Steg for steg beskrivelse av hvordan du laster ned Git </h4>
* Innstaller Git ved å trykke [her](https://git-scm.com/downloads) og velg Windows som operativsystem.
* Trykk på "Yes" når det dukker opp følgende vindu
<img src = 'img/git_windows_0.png' width = 600px>
* Trykk deretter på "Next" på vinudet som dukker opp. Denne er markert i bildet under
<imgsrc = 'img/git_windows_1.png'width = 600px>
* Nå kan du velge hvilken mappe du ønsker at programmet skal bli lastet ned i hvis du ønsker det, eller bare la foreslått filsti stå dersom du ikke har noen preferanser. Trykk deretter på "Next"
<imgsrc = 'img/git_windows_2.png'width = 600px>
* Trykk "Next" på følgende vindu
<img src = 'img/git_windows_3.png' width = 600px>
Du trenger ingen andre komponenter annet enn de som er krysset av for deg på forhånd. Du kan selvsagt velge å laste ned flere komponenter om du ønsker det.
* Trykk "Next" når du kommer til følgende vindu:
<imgsrc = 'img/git_windows_4.png'width = 600px>
* Velg Notepad++ som texteditor og trykk på "Next"
* La default valget stå, altså "Git from the command line and also from 3rd-party software" og trykk "Next"
<imgsrc = 'img/git_windows_5.png'width = 600px>
* La default valget stå på neste vindu også (vist på bildet under) og trykk "Next"
<imgsrc = 'img/git_windows_6.png'width = 600px>
* La valget stå som vist på bildet under og trykk "Next"
<imgsrc = 'img/git_windows_7.png'width = 600px>
* Samme gjelder her også. La default valget stå (vist på bildet under) og trykk "Next"
<imgsrc = 'img/git_windows_8.png'width = 600px>
* La valget stå på "Default (fast-forward or merge)" når du kommer til følgende vindu
<imgsrc = 'img/git_windows_9.png'width = 600px>
Trykk videre på "Next"
* Ikke velg noe ekstra dersom du kommer til følgende vindu og trykk "Next"
<imgsrc = 'img/git_windows_10.png'width = 600px>
* Nå spør installasjonspakken deg om du ønsker å laste ned halvferdige funksjoner. Du trenger ikke å velge noen av disse og kan bare trykke videre på "Next"
Åpne Powershell ved å søke "Powershell" der du søker etter programmer på Windows. Sjekk deretter om du har lastet ned git ved å skrive: `git --version` i programmet som dukker opp, etterfulgt av enter tasten.
Da bør det dukke opp `git version xx`som output der xx er versjonnummeret du har lastet ned.
%% Cell type:markdown id: tags:
### MacOS
%% Cell type:markdown id: tags:
Åpne Terminal-programmet (som allerede er installert), som har dette symbolet: <imgstyle="display:inline-block;"width="50px"src="img/terminal.png"> ved å søke "Terminal" i "Spotlight-søk"
%% Cell type:markdown id: tags:
Det er ganske sannsynlig at du har XCode og dermed også Git allerede lastet ned på Macen din. De nyeste modellene pleier å ha XCode. XCode er en pakke som gjør det mulig for deg å skrive kommandoer slik man gjør i Linux, og det er slike kommandoer vi skal bruke videre i denne notebooken også. XCode inkluderer også nødvendig pakker fra Git biblioteket som du kommer til å ha bruk for når du gjør oppgaver i denne notebooken og når du skal bruke Git senere i karrieren din/studiet ditt.
Aller først bør du sjekke om du allerede har Git lastet ned på Macen din.
Når du har åpnet terminalen, skriver du følgende i selve terminalen:
`git --version` etterfulgt av enter.
Lignende output bør dukke opp da i linjen under:
`git version 2.27.0`
#### Laste ned Git med XCode
Dersom du ikke har XCode på Macen din fra før av, anbefaler jeg på det sterkeste at du laster ned dette nå. Bruk følgende kommando for å laste ned de viktigste pakkene (kun command line tools og git):
`xcode-select --install`
På vinduet som dukker opp, velger du "Install" og lar installasjonen fullføres. Nå bør du kunne skrive
`git --version` igjen og versjonen bør dukke opp på terminalen.
#### Laste ned Git manuelt
Dersom du ikke ønsker å laste ned XCode men kun Git, kan du gjøre dette manuelt via linken [her](https://sourceforge.net/projects/git-osx-installer/files/). Du kan også laste ned nyeste versjon fra linken dersom du ønsker å oppgradere den nåværende versjonen av Git som er på Macen din fra før.
Følg instruksene som dukker opp. La default valg stå og ikke velg noe annet enn de som er krysset av på forhånd.
Du kan sjekke om Git ble lastet ned ved å skrive `git --version` igjen og du bør få opp `git version xx`på neste linje der xx er versjonen du har lastet ned.
%% Cell type:markdown id: tags:
### Lagre brukerinformasjon på Git
%% Cell type:markdown id: tags:
Etter at du har lastet ned Git, må du lagre informasjon om deg, slik at Git vet hvem som har gjort endringer. Det gjør du ved å skrive følgende i Terminalen (PowerShell på Windows):
`git config --global user.name "User"`
Etterfulgt av enter. I stedet for "User" må du skrive det brukernavnet du ønsker å ha på Git mellom fnuttene. Deretter må du skrive:
`git config --global user.email "Din e-mail"`
og husk å skrive din faktiske e-mailadresse mellom fnuttene. Trykk deretter på enter tasten.
%% Cell type:markdown id: tags:
# Bruk av kommandolinjen
%% Cell type:markdown id: tags:
Vi bruker Git gjennom *kommandolinjen*, så før vi kan komme i gang med Git må vi lære oss om bruk av denne.
Kommandolinjen er et brukerprogram som muliggjør å kommunisere med operativsystemet. Du kan bruke dette programmet til navigering av filene dine og til å kjøre programmer som Git. Vi skal her se på hvordan man kan navigere seg i en filstruktur lagret på PC-en. Grunnen til at vi ser på dette, er at vi må være inne i en mappe for å kunne bruke Git på innholdet. Så da må vi klare å komme oss dit! En annen grunn til at vi ser på dette er at du skal bli vant til å bruke kommandolinjen før du starter med å bruke Git.
Først skal vi se på hvordan filstier funker. Du er mest sannsynlig kjent med å bruke Finder på MacOS, og Filutforsker på Windows som gir et brukergrensesnitt på navigering og åpning av filer. Hvert innhold som ligger på Filutforsker eller på Finder, har en filsti. En filsti kan du tenke på som en slags adresse for hvordan du kommer deg til innholdet du leter etter, f.eks en mappe eller en fil. Et eksempel på en filsti kan være C:\home\user\file.txt på Windows som først peker på C-disken og viser navnet på mappene du må trykke innom før du havner på fila, "file.txt". Tilsvarende eksempel på Mac kunne være /Users/user/file.txt.
I videoen under skal vi se på hvordan du navigerer mellom mappene og filene dine som ligger lagret på PC-en din ved å bruke kommandolinjen i stedet for Filutforsker/Finder og hvordan en filstruktur fungerer. Vi skal også se kort på hvordan du kan lage en ny mappe.
Hvis du jobber på Mac, åpner du kommandolinjen i ditt operativsystem ved å søke "Terminal" i "Spotlight-søk". På Windows kan du bruke "Powershell" som gjenkjenner de samme kommandoene som brukes i videoen under. Videoen under bruker Terminalen på Mac for demonstrasjon av hvordan du bruker kommandolinjen, men disse kommandoene vil fungere helt likt hos dere som bruker Windows også. Dere som bruker Linux vet mest sannsynlig hvordan man bruker en kommandolinje til å navigere seg opp og ned i en filstruktur, slik at du kan godt hoppe over denne seksjonen dersom du kjenner til dette.
* Når man trykker på en mappe i Filutforsker (Windows) eller i Finder (Mac) og får opp innholdet i mappen, kalles det å gå *ned* i nivå i en filstruktur. Når man trykker tilbake fra en undermappe, går man *opp* i nivå i en filstruktur.
* Man bruker skråstrek (`/`) for å gå lenger ned i en filstruktur.
* Den relative filstien for å gå et nivå opp fra den mappen man står i er `..`. Man kan gå to nivåer opp ved å legge til skråstrek og `..`, altså `../..` og man kan fortsette å legge til `/..` jo flere nivåer man vil opp i en filstruktur.
%% Cell type:markdown id: tags:
## Bruk av kommandolinje, del 2
%% Cell type:markdown id: tags:
Neste video tar utgangspunkt i eksempelet fra videoen over og går gjennom grunnleggende kommandoer i bash.
Fordi du skal gjennomføre oppgavene på din egen datamaskin, med filstrukturen vi har sett på som eksempel i videoene, **må du laste ned mappa før vi starter.** Trykk først på Jupyter logoen øverst til venstre, for å komme til *Home Page*. Så trykker du på mappen "materiale", også på mappen "JN7". Deretter huker du av firkanten til venstre for "filstruktur_eksempel.zip", og trykker "Download" i menyen som dukker opp øverst på sida, som vist under.
<imgsrc="img/download_shown.png"width="400px">
Fordi dette er en zip-fil, må den **pakkes ut** (dersom den ikke gjør det automatisk). Dette gjør du som regel ved å dobbeltklikke på fila. Legg merke til hvor på datamaskinen din nedlastinga havnet. Ofte havner den i en egen "Nedlastinger"/"Downloads" mappe. Filstrukturen kan du se under "Oppsummering av video" i seksjonen over.
%% Cell type:markdown id: tags:
**Oppgave 1**
Åpne terminalen, og naviger inn i `filstruktur_eksempel` mappa du nettopp lasta ned, ved å bruke `cd <mappenavn>` kommandoen der `<mappenavn>` er navnet du gir mappen. Skriv ut innholdet i mappa.
%% Cell type:markdown id: tags:
**Løsningsforslag 1**
Tar utgangspunkt i at det er en "Nedlastninger"-mappe `filstruktur_eksempel`-mappa har havna i etter nedlasting.
Følgende kommandoer skrives inn i terminalen:
For å navigere deg til `filstruktur_eksempel` i kommandolinjen din, må du først navigere deg til `Nedlastninger` ved å skrive kommandoen
`cd Nedlastninger`
og deretter skrive
`cd filstruktur_eksempel`
i kommandolinjen for å komme deg til `filstruktur_eksempel` til slutt.
For å skrive ut innholdet, skriv
For å skrive ut innholdet i mappen, skriver du
`ls`
%% Cell type:markdown id: tags:
**Oppgave 2**
Nå som du er inne i `filstruktur_eksempel`-mappa, kom deg til mappa som fila `kode_fra_f1.py` er i (dette er markert i figuren under). Skriv ut innholdet i fila, og filstien.
*Hint:* Husk at du kan skrive `cd mappe1/mappe2/mappe3` for å gå ned tre mapper samtidig.
<imgsrc="img/kode_fra_f1_ex.png"width="400px">
%% Cell type:markdown id: tags:
**Løsningsforslag 2**
Du kan enten skrive
`cd itgk/forelesning/min_kode`
Eller gå ned en og en mappe
for å navigere deg til mappen i et steg, eller gå ned tre nivåer i tre ulike steg ved å skrive følgende:
`cd itgk`
,deretter tryker du enter
`cd forelesning`
,trykk enter
`cd min_kode`
`cd min_kode` , og trykk enter igjen.
----
For å skrive ut innholdet til fila
`ls`
hvor det printes ut
`kode_fra_f1.py`
----
For å skrive ut filstien man er i, skriver vi
`pwd`
Det som printes ut vil avhenge av hvor mappen din er lagret.
%% Cell type:markdown id: tags:
**Oppgave 3**
Nå er du inne i `min_kode` mappa, men vi ønsker å komme oss til `BM1/forelesning` mappa, som vist under. Print ut innholdet i mappa.
<imgsrc="img/up_example.png"width="400px">
*Hint:* Husk at du kan gå opp til mappa over ved å skrive `cd ../`. Du kan gå opp to mapper ved å skrive `cd ../../`.
%% Cell type:markdown id: tags:
**Løsningsforslag 3**
Kommandoen
`cd ../../../BM1/forelesning`
tar deg først tre nivåer opp til `filstruktur_eksempel` og ned til `BM1` og undermappen `forelesning` som ligger i mappen, `BM1`.
Du kan printe innholdet i `forelesning` med kommandoen
`ls`
%% Cell type:markdown id: tags:
**Oppgave 4**
Nå står du i forelesningsmappa. Bruk `mkdir` til å lage en ny mappe i BM1 (du må først navigere til denne mappa) som heter`ovinger`.
Nå står du i mappen, `forelesning`. Bruk `mkdir` til å lage en ny mappe i BM1 (du må først navigere til denne mappa) og navngi denne undermappen som`ovinger_bm1`.
%% Cell type:markdown id: tags:
**Løsningsforslag 4**
`cd ../`
Først må du navigere opp til mappen, `BM1` ved å skrive følgende kommando:
`cd ..`
`mkdir ovinger`
Nå står du i mappen, `BM1` og kan lage undermappen `ovinger_bm1` ved å skrive:
`mkdir ovinger_bm1`
Eller i ett:
`mkdir ../ovinger`
Evt. kan du både gå til mappen, BM1 og lage en undermappe der i ett steg ved å skrive følgende kommando:
`mkdir ../ovinger_bm1`
%% Cell type:markdown id: tags:
# Introduksjon til bruk av Git
%% Cell type:markdown id: tags:
Nå skal vi se på hvordan vi faktisk bruker Git ved å bruke kommandolinjen. I denne videoen skal vi bruke eksempelmappen som heter "git_introduksjon" til dette. Vi skal lage en git repo på denne mappen slik at Git begynner å spore filene og vi kan dermed bruke Git som et verktøy til å lage sjekkpunkter av endringene våre som blir gjort i innholdet i mappen i en tidslinje. Du finner mappen som blir brukt som et gjennomgående eksempel i videoen her i samme mappe som du finner denne notebooken på serveren. Trykk [her](./) for å komme til mappen. Åpne denne og pakk ut filene dersom du ønsker å være med på å gjøre eksemplene i videoen.
**Dersom du ikke allerede har installert Git, som forklart i [installasjonsguiden](#git_installasjon), burde du gjøre det nå.**
-`git init` starter en ny "repository" i prosjektet ditt.
-`git status`gir oversikt over tilstanden et prosjekt er i. Det vil si at endringene dine er synlig og Git forteller deg om endringene er "untracked" (usporet), staget eller commitet (lagret i systemet).
- For å stage en fil med navnet, "filename" bruker du kommandoen `git add filename`.
- Kommandoen `git add -all` stager alle filer og undermapper som det har blitt gjort en endring på.
-`git add .` er en alternativ kommando som stager aller filer du har gjort en endring på, eksklusiv undermapper og slettinger som har blitt gjort.
- Kommandoen, `git commit -m "<melding>"` brukes for å "commite" endringer der du erstatter`<melding>` med den commit-meldingen du ønsker å gi. Du må huske å oppgi fnutter rundt teksten som du gi som commit-melding.
%% Cell type:markdown id: tags:
## Oppgaver
%% Cell type:markdown id: tags:
Dersom du ikke allerede har gjort det, må du konfigurere Git ved å skrive
Lag en ny mappe i kommandolinjen din ved å bruke kommandoen, `mkdir` og som du kaller `my_repo`. Naviger der deretter inn i den nye mappen du nettopp lagde.
%% Cell type:markdown id: tags:
**Løsningsforslag 1**
I kommandolinjen din skriver du
`mkdir my_repo`
for å lage mappa. For å gå inn i den skriver du
`cd my_repo`
%% Cell type:markdown id: tags:
**Oppgaver 2**
Legg til filene som ligger i zip-filen, "introduksjon_til_bruk_av_git_opg2.zip" i "my_repo". Du finner zip-filen [her](./).
%% Cell type:markdown id: tags:
**Oppgave 3**
Lag en repository ved å bruke kommandoen, `git init` i kommandolinjen din. Legg til filene du lagde i oppgave 2 i staging area med kommandoen, `git add` og husk å spesifisere hvilke filer du ønsker å stage. Commit så endringene med kommandoen, `git commit` og husk å legg til en melding.
%% Cell type:markdown id: tags:
**Løsningsforslag 3**
For å lage en ny "repository" skriver du
`git init`
Du får da ut en melding som starter med "Initialized empty Git repository in ... " (hvilken filsti avhenger av hvor på datamaskinen din du lagret mappa)
For å legge til alle filene dine i staging area, skriver du følgende kommando:
`git add --all`
For å commite filene dine som ligger i staging area, bruker du følgende kommando:
`git commit -m "Initial commit"` (Eller hvilken som helst annen melding som du skriver mellom fnuttene)
%% Cell type:markdown id: tags:
**Oppgave 4**
Legg til noe tekst tekstfilene, "tekstfil.txt" i mappa, og commit endringene du gjorde.
%% Cell type:markdown id: tags:
**Løsningsforslag 4**
Etter at du har lagret endringen på tekstfilen, må du stage filen med kommandoen
`git add tekstfil.txt`
og deretter kan du commite endringen med
`git commit -m "melding"`.
Du kan velge å skrive en annen melding mellom fnuttene.
%% Cell type:markdown id: tags:
# Mer om Git
%% Cell type:markdown id: tags:
Denne seksjonen kommer til å nevne noen nyttige Git kommandoer som kan være greit å bruke i noen tilfeller. Det finnes mange andre kommandoer i Git som du kan lese mer om på Gits offisielle dokumentasjon når du først har blitt mer komfortabel med å bruke Git. Denne seksjonen ligger på et litt høyere nivå enn de andre seksjonene, så fortvil ikke om det er noen kommandoer du ikke forstår med det første. Kommandoene som blir introdusert i denne seksjonen kommer mest sannsynlig til å gi enda mer mening når du begynner å bli mer komfortabel med å bruke Git, så det anbefales å komme tilbake til denne seksjonen senere etter at du har blitt vant med Git dersom det er noen kommandoer du enda sliter med å forstå.
%% Cell type:markdown id: tags:
## Få oversikt
%% Cell type:markdown id: tags:
Git tilbyr spesielt to nyttige kommandoer som gir deg oversikt over endringer som blir gjort underveis. Disse er `git log` og `git status`. `git status` har allerede blitt nevnt og brukt i forrige seksjon men denne seksjonen repeterer kommandoen likevel og viser en output som kommer opp om du gjør andre endringer enn kun å legge til en fil.
`git status` gir deg en liste over filer som enten er endret, lagt til eller slettet, der disse endringene ikke har blitt commitet eller staget enda. Bildet under viser et eksempel på en output som kan dukke opp om du *endrer* på filer.
<imgsrc = 'img/git_status.png'width = 600px>
I eksempelet har filene "oving.py" og "tekstfil.txt" blitt endret på og derfor blitt markert som "modified". Det kommer også en tydelig markering dersom en fil er slettet. Disse markeres som "Deleted". I begge tilfeller vil filene havne under "Changes not staged for commit" før du stager dem og commiter. Som du antageligvis husker fra forrige seksjon, vil nye filer som er lagt til i prosjektet havne under "Untracked files" fordi de enda ikke har blitt sporet av Git før du begynner sporingen.
Bildet under viser et eksempel der det har blitt slettet noen filer som Git sporer fra før av, og lagt til nye filer i et prosjekt som Git ikke har begynt å spore enda, og hva `git status` da viser i dette tilfellet. Som forventet havner slettede filer under "Changes not staged for commit" fordi disse ikke er staget eller commitet enda og filer som er nye i prosjektet havner under "Untracked files".
`git log` gir deg en tekstlig liste over alle commits som har blitt gjort. ID-en, forfatter, dato og meldingen til commitene dukker opp. Denne kommandoen kan være greit å bruke for å få en oversikt over hvilke endringer det er som har blitt gjort. Gode commit meldinger er derfor svært viktige for at andre medlemmer klarer å forstå endringene som har blitt gjort på et prosjekt. Bildet under viser et eksempel på commits som har blitt gjort på et prosjekt. Det som står i parentes, er navnet til branchen der commiten ble gjort. Du kan foreløpig ignorere hva "origin/master" er.
<imgsrc = 'img/git_log.png'width = 600px>
Du kan få en finere format på outputen ved å legge til `--oneline` som flagg, altså blir hele kommandoen `git log --oneline`.
*Hint: Om du ønsker å avslutte prosessen siden den bruker tid på å laste opp alle commitene dine, kan du taste inn `ctrl + c`.*
%% Cell type:markdown id: tags:
## Slette endringer og rulle tilbake i commit historikken
%% Cell type:markdown id: tags:
<h4> Rulle tilbake til gammel tilstand av prosjektet </h4>
På samme måte som du kan velge branch med <code>git checkout</code>, kan du også velge en commit du ønsker å gå tilbake til med samme kommando. Denne kommandonen kan hjelpe deg å finne fram til en sikker kopi av prosjektet i tidslinjen over alle endringer som har blitt gjort dersom du har støtt på uheldige endringer som på et vis har ødelagt prosjektets innhold. Du kan altså gå til en kjent tilstand som du vet er trygg. Du kan tenke på det som om du flytter en peker tilbake til en tidligere commit, evt. skrur tilbake "tiden". Da må du spesifisere hvilken commit du ønsker å gå tilbake til. Dette gjør du ved å oppgi hash-verdien til commiten du vil gjøre en <code>checkout</code> på (altså flytte peker til). Du kan finne denne hash-verdien ved å søke deg gjennom commithistorikken med kommandoen <code>git log --oneline</code> som gir deg en liste over alle commits som har blitt gjort på den branchen du står i. Hash-verdien vil bestå av en blanding av tall og bokstaver, som f.eks "a1e8fb5". Når du har gjort en <code>checkout</code> på en tidligere commit, vil innholdet i prosjektet ditt endre seg til hva den var da valgt commit ble gjort (den du velger med <code>checkout</code>). Merk at når du bruker <code>git checkout commit_id</code> der "commit_id" er hash-verdien til commiten du vil peke på, så vil ingen endringer du gjør bli lagret i Git repoet. Du kan komme tilbake til "redigeringsmodus" i Git ved å skrive <code>git checkout master</code> gitt at master holder nyeste versjon av prosjektet og master er "hovedgrenen" din (den du alltid bruker til å lagre siste versjon av koden din i). Da vil du også få nyeste commit i master dersom du nå commiter en ny endring. Da kan du f.eks lime inn den sikre kopien av prosjektet, eller bruke <code>git revert</code> eller <code>git reset</code> som er mer elegante løsninger.
<h4>Slette commits med <code>git reset</code> og <code>git revert </code></h4>
Du kan angre nyeste commit med kommandoen <code>git revert HEAD</code> som vil rulle tilbake den siste endringen som ble gjort i prosjektet. Da vil ikke prosjektet ha samme tilstand som den hadde under denne commiten lenger. I praksis sletter du ikke commiten, den finnes i tidslinjen enda og det går an å se den under commithistorikken med kommandoen, <code>git log --oneline</code>. Du vil i praksis kun lage en ny commit som gjør om siste commit før du kalte på <code>git revert HEAD</code>.
Du kan også angre andre commit ved å legge til ID-en til ønskelig commit i stedet for "HEAD".
Når du skriver <code>git revert HEAD</code> og deretter enter, vil Git be deg om å gi en commit melding på handlingen, og dette dukker opp i en teksteditor. Noen av dere har antageligvis Vim som standard teksteditor og Git vil da åpne Vim for deg der du kan skrive commit meldingen din og lagre. Dere som bruker Windows og har fulgt installasjonsguiden som står lenger oppe i denne notebooken, har valgt notepad ++ som teksteditor og da vil det åpne opp et nytt vindu i notepad ++. Du må skrive commit meldingen din og lagre når du får opp vinduet. Hvis du får opp en annen teksteditor og ikke vet hvordan du lagrer tekstfilen som dukker opp i teksteditoren, anbefales at du Googler hvordan du lagrer en fil der.
Dersom du har Vim som teksteditor, vil følgende vindu dukke opp:
<imgsrc = 'img/git_revert_head.png'width = 600px>
Hvis et slikt vindu dukker opp, trykk på "esc" tasten etterfulgt av ":wq" og enter. Da skal det dukke opp en commit melding i loggen hvor det står "Revert "commit melding"" der "commit melding" er meldingen til commiten du angret på med <code>git revert</code>. I bildet under, har det blitt gjort en "revert" på commiten med ID-en, "63c7dd7", og det har blitt lagt til en ny commit melding hvor det står "Revert "Dårlig commit"".
Dersom du i tillegg ønsker å slette dine dårlige commits fra historien, kan du bruke <code>git reset --hard commit_id </code> i stedet der "commit_id" er hash-verdien til den siste commiten du ønsker å ha med i din nye tidslinje. Kommandoen sletter alle commits som kom *etter* den commiten du oppgir i kommandoen, mens resten beholdes. Skriver du <code>git log --oneline</code> nå, vil du se den oppdaterte tidslinjen din.
ønsker vi å slette commiten med meldingen, "Dårlig commit", altså den med ID, "855241f".
Skriver vi nå <code>git reset --hard fb4c6a2</code>, vil commit med hash-verdien "855241f" bli slettet og HEAD (pekeren) vil peke på commiten med ID-en, "fb4c6a2" som vist i loggen under
<imgsrc = 'img/etter_reset.png'width = 600px>
Denne kommandoen vil fungere dårlig dersom en commit du ønsker å slette allerede er pushet til en remote repo. For det er ikke mulig å pushe en ny "tidslinje" hvor du har brukt <code>git reset</code> hvis de slettede commitene ligger ute. Git vil fange opp dette og tro at din tidslinje ligger bak den som ligger ute. I slike tilfeller er det bedre å bruke <code>git revert</code>i stedet fordi denne kommandoen lager en ny tidslinje og vil ikke "kutte" en gammel tidslinje som ligger remote. Men du kan trygt bruke reset for å slette *lokale* commits som enda ikke har blitt lagt ute.
#### Slette fil som er i working area
Du kan bruke `git checkout <filename>` for å slette endringer som har blitt gjort på en fil, der `<filename>` er navnet på filen du ønsker å slette endrigner på. Da må filen ikke være staget eller commitet enda, men være i working area. En alternativ kommando du kan bruke for å gjøre akkurat det samme, er `git restore "filename"` der "filename" er fila du vil angre endringer på. Bruker du en av disse kommandoene, vil altså filen gå tilbake til sin opprinnelige tilstand før du gjorde endringer på den. Disse kan være greit å bruke dersom du gjør endringer som fører til mye feil og ønsker å gå tilbake til den originale filen som var i prosjektet før du begynte med endringene dine.
Dersom du har en staget fil du ikke ønsker å commite likevel men slette endringen til, kan du først bruke `git reset --mixed <filename>` der `<filename>` er navnet på filen, for å flytte filen tilbake til working area (eng:unstage). Deretter kan du bruke enten `git checkout` eller `git restore` for å slette endringen som ble gjort.
Du kan slette *usporede* filer som du har lagt til i prosjektet som ligger enda i working area og som du ikke ønsker å ha med i prosjektet likevel. Disse vil ligge under "Untracked files" når du bruker kommandoen `git status`. Du kan slette disse filene med kommandoen `git clean -d -i`. Men før du bruker kommandoen kan det være lurt å se først hvilke filer den da kommer til å slette ved å skrive `git clean –d -n` i stedet. Sistnevnte kommando sletter ikke de usporede filene, men vil i stedet gi deg en liste over de filene som kommer til å bli slettet hvis du bruker kommandoen `git clean -d -i`.
%% Cell type:markdown id: tags:
## Git diff
%% Cell type:markdown id: tags:
`git diff <filename>` der `<filename>` er navnet på filen du ønsker å inspisere, er en nyttig kommando som kan brukes både under merge conflicts (som kommer til å bli introdusert i en senere seksjon) og før man stager en fil. Du må huske å ha fnutter rundt filnavnet når du bruker kommandoen.
Kommandoen printer ut endringer som har blitt gjort på filen du gir som argument på tekstlig format i kommandolinjen. Kommandoen vil vise deg linjer som har blitt slettet og linjer som har blitt lagt til i filen siden siste commit. Linjer som er markert med rødt minustegn er slettede linjer og de som er markert med grønt plusstegn er linjer som er lagt til. Bildet nedenfor viser et eksempel der `git diff` er brukt på en fil som heter 'oving1.py'
<imgsrc = 'img/git_diff.png'width = 600px>
Alternativt kan du bruke `git difftool <filename>` for å få en annen visualisering av `git diff`. `git difftool` sammenstiller den eldre tilstanden til filen med den nye tilstanden der endringene er lagt til i teksteditoren du har satt som standard for kommandolinjen din. Med dette verktøyet kan du sammenligne linje for linje hva som har blitt slettet eller lagt til i en fil. Et eksempel er vist i bildet under
<imgsrc = 'img/git_difftool.png'width = 600px>
Bildet over viser et eksempel der filen åpnes i Vim. Dette vil skje automatisk dersom du har Vim som en standard teksteditor. Om du skulle støte på problemer ved å bruke `git difftool` kommandoen, anbefales det at du bruke `git diff` i stedet. Du kan også konfigurere Git slik at kommandoen åpner filen du ønsker å undersøke i et annet program i stedet dersom du skulle ønske det, men det blir ikke gitt noen guide på dette i denne notebooken. Det anbefales at du Googler deg fram til dette selv.
Merk at når du skriver kommandoen `git difftool`, spør Git deg om du ønsker å gå videre. Et skjermbilde av meldingen som dukker opp er vist på bildet under
Hvis du ønsker å gå videre må du skrive y og deretter enter. Dersom du ikke ønsker å åpne difftool, trykker du på n og deretter enter.
%% Cell type:markdown id: tags:
## Ignorere endringer i et prosjekt
%% Cell type:markdown id: tags:
Det er mulig å be Git om å se bort i fra visse filtyper som ikke er viktig å ha med i repoet. Du kan gi en liste over filer du ønsker at Git skal ignorere i noe som kalles for en .gitignore fil. En .gitignore fil, er en tekstfil som gir en liste over hvilke filtyper Git skal se bort i fra dersom de blir lagt til i prosjektet. Ofte, når du programmerer, kan det lages automatiske filer du ikke behøver i repoet ditt. Det går an å legge disse filene i en .gitignore fil for å sørge for at disse ikke blir fanget opp som "Untracked files". Eksempel på dette er checkpoint filer som dukker opp når du jobber på en jupyter notebook eller .DS_store som filsystemet til Mac lager.
Du lager en .gitignore fil ved å legge til en vanlig tekstfil (på txt format) som du navngir ".gitignore" i samme mappe som prosjektet ditt ligger i. I denne filen, skriver du filformatet til de type filene de ønsker å ignorere. Dette gjør du ved å enten skrive ut filnavnet (f.eks .DS_Store som er en fil som MacOSX genererer) eller <p>*</p> etterfulgt av endelsen som kommer med filnavnet, ofte på formatet ".fileformat" der fileformat er formatet på filen du ønsker at Git skal ignorere. Hvis du f.eks. vil ignorere alle filer som slutter på ".ipynb_checkpoints" skriver du bare:
<p>*.ipynb_checkpoints</p>
i tekstfilen som du har kalt for .gitignore.
Du må nå sørge for å legge til din nye .gitignore filen i Git repoet ditt med å først stage den med kommandoen `git add .` og commite med `git commit -m ".gitignore fungerer"`. Nå vil Git sørge for å slutte å fange opp filer som er listet i .gitignore hver gang en slik fil blir lagt til i mappen din gitt at du aldri har staget og deretter commitet slike filer tidligere.
Dersom du ønsker å ignorere filer som allerede har blitt commitet tidligere, hjelper det ikke å kun liste opp filen i .gitignore fordi Git vil ikke ignorere filen likevel. Du må slette filen fra repoet først og det er først da .gitignore fil fungere på filen. Du sletter en fil fra Git repoet med kommandoen `git rm --cached <filename>` der `<filename>` er navnet på filen du ønsker at Git skal slutte å spore.
Dersom det er mange filer du har commitet som du ønsker at Git skal ignorere, kan det være mer effektivt å først flytte alle filene som ligger i Git repoet til working area først med kommandoen,
`git rm -r --cached`
Deretter kan du bruke kommandoen, `git add .` som sørger for å stage filer som ikke er listet i .gitignore.
Lag deretter en commit (husk å ha med flagget, -m, etterfulgt av commit-meldingen) og nå vil Git være oppdatert etter .gitignore. Nå vil filer som tidligere har blitt sporet av Git men som nå har blitt lagt til i .gitignore, faktisk bli ignorert neste gang.
%% Cell type:markdown id: tags:
# Om branching og merge
<aid="om_branch_og_merge"></a>
%% Cell type:markdown id: tags:
<h3> Hva er branch og merge?</h3>
Vi har nå sett på det mest grunnleggende i Git. Men det finnes enda mer, og nå skal vi se på hvordan vi kan dele opp i flere parallelle branches(grener), som vi kan arbeide på. Vi skal også se på hvordan vi kan slå sammen disse branchene slik at også endringene blir slått sammen ved en *merge*.
En *branch* kan du tenke på som en tidslinje over ulike commits som har blitt gjort i prosjektet ditt. Hver commit er laget i ulik tid der hver av dem tilsvarer en versjon av koden. Den nyeste commiten i prosjektet ditt vil altså være den nyeste versjonen av koden din. Når du for første gang lager et Git repo og har tillatt Git å spore filene dine ved å stage innholdet i mappen din og deretter lage din første commit, lages det automatisk en branch for deg som kalles *master*.
En branch tilsvarer en tidslinje over alle endringene du har gjort, og du kan ha flere tidslinjer separert fra hverandre ved å lage flere branches fra den branchen du er i som du kan jobbe videre i. Da vil den nye branchen du lager inneholde alle endringer som har blitt gjort i prosjektet hittil før branchen ble opprettet, men nye endringer du gjør fremover vil holde seg isolert fra den opprinnelige branchen du var i, som du kan tenke på som en egen tidslinje og et eget "arbeidsmiljø". Når du lager en branch, kan du tenke på denne som en oppsplitting av den første tidslinjen du hadde før du lagde den nye branchen din. Figuren under illustrerer denne metaforen. Hver runding representerer en commit i historien og en kjede av disse "rundingene" (commits) tilsvarer en egen branch. Hver branch har et eget navn. Den øverste branchen i figuren heter *master* og den andre heter *developer*. Developer er den branchen som har blitt laget fra master. Den vil inneholde de tidligere commitene fra master fram til den siste (siste runding i figuren), men i tillegg vil den inneholde de nye commitene du legger til mens du jobber i developer branchen, som er illustrert som to nye rundinger. Disse commitene finnes ikke i master fordi du har splittet opp tidslinjen som master følger.
<imgsrc = 'img/branches.svg'width = 600px>
Når du endelig er fornøyd med de nyeste endringene du har lagt til i den nye tidslinjen (i den nye branchen), kan du endelig slå sammen den nye branchen med den opprinnelige ved å flette de sammen (eng:*merge*). Da vil Git forsøke å sette sammen alle commits som har blitt gjort på begge branchene sammen. Når du gjør en merge (slår sammen) to branches, vil Git lage en ny commit i tidslinjen til den branchen du merger *til*. Figuren under illustrerer hva som skjer når du slår sammen to branches som heter master og developer.
<imgsrc = 'img/merge.svg'width = 600px>
Tidslinjen til developer og master blir gjenforent når du merger developer inn i master.
Videoen under kommer til å vise kommandoer for å lage branch, slå sammen branches og for å se hvilken branch man jobber på. Konseptene branch og merge kommer forhåpentligvis til å bli tydeligere når du har sett ferdig videoen.
- Vi skriver `git branch` for å se hvilke branches vi har, og hvilken branch vi er i.
- Master branchen blir laget automatisk, og er den vi er i automatisk.
- For å lage en ny branch skriver vi `git branch <branchname>` der du erstatter `<branchname>` med det navnet du ønsker å gi branchen (grenen) din.
- Vi bytter branch ved å skrive `git checkout <branchname>` der du erstattet `<branchname>` med navnet på branchen du vil bytte til.
- Du sletter en branch med navnet `branchname` ved å skrive kommandoen, `git branch -d <branchname>`.
- For å merge to branches (grener), må vi først bytte branch til den vi skal merge med, og skriver så `git merge <branchname>`, hvor `<branchname>` er navnet til branchen vi merger med.
- Ofte vil man da først bytte branch til master, også merge med branchen vi har arbeidet på.
%% Cell type:markdown id: tags:
## Oppgaver
%% Cell type:markdown id: tags:
**Oppgave 1**
Naviger til den samme mappa du lagde i "Introduksjon til bruk av Git" seksjonen. Lag en ny branch og kall den for `new_branch`.
%% Cell type:markdown id: tags:
**Løsningsforslag 1**
Naviger til ønsket mappe ved å skrive kommandoen, `cd <filsti>` der du oppgir filstien til mappen du lagde i "Introduksjon til bruk av Git".
Lag deretter branchen, "new_branch" ved å skrive `git branch new_branch`
%% Cell type:markdown id: tags:
**Oppgave 2**
Bytt branch til `new_branch`.
%% Cell type:markdown id: tags:
**Løsningsforslag 2**
Du bytter til "new_branch" ved å skrive følgende kommando
`git checkout new_branch`
%% Cell type:markdown id: tags:
**Oppgave 3**
Gjør noen endringer i to av filene, stage disse filene, og commit endringene mens du står i `new_branch`. Bruk `git log --oneline` for å bekrefte at commiten ble gjort.
%% Cell type:markdown id: tags:
**Løsningsforslag 3**
Du stager alle filene dine ved å bruke kommandoen
`git add --all`
og commiter med `git commit -m "Gjorde noen endringer"`
%% Cell type:markdown id: tags:
**Oppgave 4**
Bytt nå branch til master, og skriv `git log --oneline` for å bekrefte at commiten vi gjorde i den andre branchen ikke er her. Merge `new_branch` til `master`. Slett så branchen du lagde tidligere. Bruk kommandoen `git branch` for å sjekke om branchen ble slettet. Den bør nå ikke listes opp lenger under aktive grener i kommandolinjen din.
%% Cell type:markdown id: tags:
**Løsningsforslag 4**
For å bytte til master skriver du `git checkout master`.
Nå merger du "new_branch" til master ved å skrive `git merge new_branch`.
Slett "new_branch" ved å skrive kommandoen, `git branch -d new_branch`.
%% Cell type:markdown id: tags:
# Konflikter i Git
%% Cell type:markdown id: tags:
Noen ganger kan det oppstå problemer når man skal "merge" to grener. Dette kalles for en "merge conflict" og oppstår fordi linjer i koden i de to grenene er ulike. Konflikten kan også oppstå om det har blitt gjort endringer på en fil i en branch mens filen har blitt slettet i en annen branch som man i ettertid prøver å merge til. Git vil da ikke tillate deg å gjøre en merge før du løser konflikten, som er noe vi skal se mer på i denne videoen.
- Dersom linjer i en kode har ulikt innhold på ulike grener, får vi "merge conflict".
- Git vil gi en melding der det står "CONFLICT (content): Merge conflict in filename", hvor "filename" vil være filnavnet konflikten skjedde i.
- Kan også se fra `git status` hvilken fil konflikten var i ved at de står under "Unmerged paths"
- Vi må selv bestemme hvilken av linjene vi ønsker å beholde.
- Må løse konflikten ved å fjerne linjen vi ikke vil ha med, og fjerne linjene hvor det står "<<<HEAD","======"og">>>>>> <branchname>".
- Når dette er fjernet, commiter vi filen, ved å skrive `git commit -m "<melding på løst konflikt>"`, og da ser Git på konflikten som løst. Det kan være lurt å skrive i meldingen at denne løser en konflikt.
%% Cell type:markdown id: tags:
## Mulige løsninger til "merge conflicts"
%% Cell type:markdown id: tags:
* Du kan se en logg over commits som har konflikt med hverandre med kommandoen `git log --merge`. Denne kan være grei for å kunne hente ut ID-en til commitene som er i konflikt med hverandre(består av en lang hash). Da kan man velge å rulle tilbake eventuelle dårlige commits.
* Du kan evt. bruke `git diff <commit1> <commit2>` der `<commit1>` og `<commit2>` erstattes med hash-verdiene til commitene du ønsker å sammenligne for å se differansen mellom commits som er i konflikt med hverandre.
* Kommandoen `git diff <branch1> <branch2>` der `<branch1>` og `<branch2>` er navnet på branchene som er i konflikt, kan hjelpe deg å se forskjellen mellom to ulike branches. Dette kan du bruke for å se hva som er forskjellen mellom branchene som er i konflikt.
* Du kan angre en forsøkt merge med kommandoen `git merge --abort`.
* Kommandoen `git status` vil fortelle deg hvilke(n) fil(er) branchene har en konflikt på. Ved å bruke `git status` kan du finne de filene du må inspisere videre ved en merge conflict.
%% Cell type:markdown id: tags:
# Bruke Git i et samarbeid
<aid='git_samarbeid'></a>
%% Cell type:markdown id: tags:
## Hva er remote repository?
%% Cell type:markdown id: tags:
Som det ble nevnt under "Introduksjon til versjonskontroll, Git og installasjon", er Git et viktig samarbeidsverktøy for deling av kode. Det er her *remote repository* kommer til nytte. Et remote repository er et Git repository, altså et lager for koden du skriver, men i stedet for å ligge lokalt på PC-en din, ligger en remote repository på nettet. En remote repository fungerer som en skylagring for prosjektet ditt, og det finnes flere tjenester som tilbyr servere for prosjektet ditt og som er integrert med Git. To veldig populære eksempler som du mest sannsynlig vil støte på både videre i studiet ditt og i arbeidslivet, er GitHub og GitLab. I denne seksjonen skal vi bruke GitHub som et gjennomgående eksempel. Du kan lage en bruker på GitHub ved å trykke [her](https://github.com/). Hvis du ønsker å være med på å gjennomføre eksemplene gitt i videoen under, må du ha en bruker fra før.
Når du lager en remote repository, vil du i praksis publisere et prosjekt på en nettside til den tjenesten du bruker. Bildet under viser GitHub som eksempel der den lokale repositoryen som ble laget i seksjonen, [Introduksjon til versjonskontroll, Git og installasjon](#introduksjon_git), er publisert.
<imgsrc = 'img/github_eksempel.png'width = 800px>
Merk at når vi lager en remote repo av et prosjekt, vil ikke det nødvendigvis bety at vi *offentliggjør* koden, det er mulig å endre synligheten på prosjektet selv om det ligger ute på nettet. Det vi i praksis gjør, er å lagre koden på en ekstern server.
En slik tjeneste fungerer nesten som Google Drive og OneDrive, der du kan skylagre endringene dine. Poenget med å bruke en slik tjeneste er å ha en felles lagringsplass som alle kan ha tilgang til. Flere kan gjøre endringer på det samme prosjektet lokalt på PC-en, publisere disse og hente ut siste versjon av prosjektet som ligger ute på tjenesten. Publisering av en versjon av koden kan du gjøre med `push` kommandoen og uthenting av nyeste versjon som ligger ute på nettet kan du gjøre med `pull` kommandoen.
En god arbeidsflyt kan være å jobbe isolert med egen versjon av et prosjekt lokalt på PC-en. Dette kan man gjøre via den lokale kopien av repositoryen på en egen branch. I tillegg vil man holde de endringene av prosjektet som skal være endelige og som er regnet som *ferdige* i hovedbranchen som oftest er master. Dette er branchen som automatisk lages første gang noen lager en git repository som vi har sett på i forrige seksjon. Når man har lagret sin versjon av prosjektet ved å commite på sin gren og ønsker å få inn disse endringene inn i master der de endelige endringene fra de andre medlemmene ligger, kan man merge til master som vi så på i forrige seksjon.
Bruk av disse kommandoene kommer til å bli illustrert i videoen under.
## Skrevet feil brukernavn og passord på Windows? Trykk her for mer informasjon om hvordan du kan fikse problemet!
%% Cell type:markdown id: tags:
Når du skriver feil brukernavn og passord på Windows en gang, vil operativsystemet ditt lagre dette under 'Legitimasjonsbehandling' (*eng: Credential Manager*) i Kontrollpanelet (*eng: Control Panel*) og hver gang du forsøker å bruke kommandoen `push` og `pull`, vil du slite med å få tillatelse til å gjøre disse handlingene fra den tjenesten du bruker for din remote repository. Windows vil ikke be deg om å skrive brukernavn og passord på nytt, så du må gå inn på kontrollpanelet og gjøre dette selv.
1. Søk på 'Kontrollpanel' i søkefeltet ved windowsknappen som vist i bildet under:
<img src = 'img/kontrollpanel.png' width = 400px>
og trykk deg videre på kontrollpanel. (*eng: Control Panel*)
2. Trykk deretter på 'Brukerkontoer' markert i figuren under
4. Trykk på 'Windows-legitimasjoner'. Der får du opp en liste med brukernavn og passord som har blitt lagret for diverse tjenester. Naviger deg fram til https://github.com/ under 'Generell informasjon' (*eng: General Credential*)
(evt. en annen hvis du ikke bruker GitHub, som f.eks GitLab), trykk videre på dropdown-menyen og trykk deretter på 'Fjern' (*eng: Delete*). Du kan eventuelt endre på brukernavn og passord ved å trykke på 'Rediger' (*eng: Edit*) i stedet for. Da må du fylle inn brukernavn og passordet ditt på GitHub (evt. en annen tjeneste om du bruker det).
5. Nå kan du bruke Git igjen som vanlig i kommandolinjen din (Powershell). Prøv å skriv inn kommandoen som feilet på nytt. Nå bør Git be deg om å skrive brukernavn og passord på nytt.
%% Cell type:markdown id: tags:
## Oppsummering av video
%% Cell type:markdown id: tags:
* For å koble sammen en remote repository på nettet med et prosjekt som ligger lokalt på pc-en for at man skal kunne publisere og hente endringer fra nettet på prosjektet, skriver man følgende kommando i terminalen:
`git remote add <name of remote repository> <url to remote repository>`
Bare husk å erstatte hva som står i mellom `<>`med det riktige navnet på remote repository og url-en.
Det vanligste er å gi navnet, 'origin' på den remote repositorien.
* For å publisere endringer som er gjort i et prosjekt lokalt på en PC på en nettjeneste som f.eks GitHub, brukes kommandoen `push`. Du må spesifisere navnet på den remote repoet du vil pushe *til* hvilken lokale branch du vil pushe endringene dine *fra*. Den fulle kommandoen du skriver i terminalen er:
`git push <name of remote repo> <the branch you want to push from>`
Husk også her å erstatte hva som står i `<>`med riktig navn på den remote repositorien (som oftest origin hvis du følger standarden) og navnet på branchen (master hvis du følger den vanlige arbeidsflyten som er anbefalt fra videoen)
Hvis du f.eks vil pushe fra din lokale branch som heter master til den remote branchen som heter origin, skriver du:
`git push origin master`
* For å slå sammen endringene fra en branch til en annen, bruker du *merge*. Da må du stå i den branchen du vil flette endringene dine til. Bruk `checkout` kommandoen for å bytte branch. Den fulle kommandoen for merge er:
`git merge <branch to merge from>`
* For å hente endringer som har blitt gjort på fra den remote repositorien, brukes kommandoen `pull`. Da må du spesifisere hvilken lokale branch du ønsker å hente endringene dine til, og navnet på den remote repositorien du vil hente kode fra. Den fulle kommandoen for å bruke pull er:
`git pull <remote branch> <local branch>`
Husk at du må erstatte hva som står i `<>` med korrekt navn på remote repository og navn på den lokale branchen du vil pulle til. Oftest henter man endringene til master og den remote repositorien heter origin hvis du bruker den standard konvensjonen. Da henter du endringene fra GitHub (evt. andre tjenester du bruker) til master som ligger lokalt på PC-en din ved å skrive:
`git pull origin master`
* Du kan hente en lokal kopi av et prosjekt som ligger på en remote repository på nettet (f.eks på GitHub). Dette kalles å klone et prosjekt. Du kloner et prosjekt med kommandoen, `clone`. Den fulle kommandoen blir:
`git clone <url to remote repository>`.
Hvis du f.eks vil klone prosjektet som ligger i følgende link: https://github.com/victorah96/git_tutorial.git
Hvis du ikke har gjort det enda, lag en bruker på GitHub [her](https://github.com/).
Logg inn og lag en remote repo på GitHub.
%% Cell type:markdown id: tags:
**Løsningsforslag 1**
Trykk på pluss-tegnet i navigasjonslinjen øverst og deretter på "New repository" som vist i bildet under:
<imgsrc = 'img/new_repo.png'>
Fyll ut feltene som kommer opp.
<imgsrc = 'img/new_repo_fields.png'width = 500px>
Det viktigste er å gi repoet et navn og velge synlighet.
Kopier linken til repoet du nettop lagde ved å trykke på knappen markert i figuren under:
<imgsrc = 'img/copy_repo.png'>
%% Cell type:markdown id: tags:
**Oppgave 2**
Lag en mappe og lag en tekstfil ved navnet "filnavn.txt" som du plasserer i mappen din. Lag en lokal Git repo i mappen din.
%% Cell type:markdown id: tags:
**Løsningsforslag 2**
Åpne Terminalen/Powershell og bruk `mkdir` kommandoen til å lage en mappe. Husk å oppgi navn til mappen. Legg til en tekstfil enten ved å bruke Notepad (Windows) eller `touch` kommandoen (dersom du bruker Mac eller Linux) direkte i Terminalen (da skriver du `touch filnavn.txt` der du kan erstatte "filnavn.txt" med et annet navn på filen om du vil, men du må ha med .txt endelsen.)
Naviger deg til mappen du nettopp lagde i Terminalen med kommandoen, `cd` og lag en Git repo med kommandoen:
`git init`
Stage og commit tekstfilen din ved å først skrive:
`git add .`
og deretter `git commit -m <melding>`, der du kan erstatte `<melding>` med den commit-meldingen du ønsker å gi.
%% Cell type:markdown id: tags:
**Oppgave 3**
Publiser innholdet i den lokale repoen du lagde i forrige oppgave, til den remote repoen som du lagde på GitHub.
%% Cell type:markdown id: tags:
**Løsningsforslag 3**
Sørg for at du har commitet alle endringene dine først. Sjekk om du har gjort det med `git status` kommandoen.
Først må du koble den remote repoen på GitHub med din lokale repo. Dette gjør du med kommandoen
`git remote add origin <url>` der du erstattet `<url>` med den linken du kopierte i oppgave 1 (linken til din repo på GitHub).
For å publisere innholdet ditt på GitHub, skriver du
`git push origin master`
%% Cell type:markdown id: tags:
**Oppgave 4**
*Kommentar: Denne oppgaven krever at du bruker en annen datamaskin enn den du brukte i oppgave 1-3. Det anbefales at dere jobber to stykker med denne oppgaven.*
Klon prosjektet du lagde i oppgave 1-3 til en annen datamaskin enn den du brukte i oppgave 1-3. Legg til en ny linje i tekstfilen "filnavn.txt" mens du står i master branchen din. Push endringene dine til GitHub. Etter at du har gjort det, åpne Terminalen/Powershell på den datamaskinen du brukte i oppgave 1-3, naviger til riktig mappe (den du lagde i oppgave 1) og hent til slutt endringene fra GitHub til datamaskinen din med `pull` kommandoen.
%% Cell type:markdown id: tags:
**Løsningsforslag 4**
Du kloner et prosjekt med følgende kommando:
`git clone <url>` der du må oppgi URL-en til prosjektet som ligger på GitHub.
For å pulle siste endringene som ligger på GitHub til lokal master, skriver du
`git pull origin master`
%% Cell type:markdown id: tags:
## Forslag på arbeidsflyt ved samarbeid
%% Cell type:markdown id: tags:
Når du begynner å bruke Git i samarbeid, er det viktig å velge en arbeidsflyt som fungerer både for deg og teammedlemmene dine. Du ønsker helst å passe på å slå sammen endringer med få konflikter som mulig når flere jobber på samme prosjekt. Denne seksjonen gir et forslag på en arbeidsflyt som er vanlig å bruke i store prosjekter. Det kan være greit for deg som er ny på Git og ny på å samarbeide på samme kode å ha sett på dette forslaget en gang for alle.
1. Før du begynner arbeidet ditt, sørg for å holde din lokale master oppdatert i forhold til den som ligger ute på nettet. Gå inn i master branchen din hvis du ikke er der allerede, og bruk kommandoen:
`git pull origin master`
For å hente de siste endringene som ligger ute.
2. Det er svært viktig å jobbe i separate branches etter at man har fordelt arbeidsoppgavene i et prosjekt. Det er meningen at hver branch skal tilsvare en andel i prosjektet som er under arbeid. Dette er typisk en ny funksjonalitet eller så kan det f.eks være en Python fil som svarer på en øvingsoppgave i ITGK. Poenget er at et arbeid skal gjøres på en egen branch. Sørg for å navngi branchen til noe som beskriver arbeidsoppgaven godt. F.eks 'oving1_itgk'. Å jobbe i branches, sørger for å isolere arbeidsmiljøet til hver bruker. På den måten sørger du for å holde uferdige endringer unna hovedgrenen (master) og passer på å holde en tidslinje som inneholder de endelige versjonene av prosjektet.
3. Commit så ofte som mulig for hver endring du gjør. Prøv å unngå å lage store commits på en gang. Sørg for å gi en beskrivende og passende melding på commiten. F.eks. `git commit –m 'Har lagt til en ny pythonfil for øving 1 i ITGK'`. Du må huske å stage endringene du ønsker å commite før du commiter. Du bruker `git add <file>` der `<file>` er filnavnet du skal stage, til dette. Evt. `git add .` for å ta med alle endringer. Små commits hjelper deg å holde en oversiktlig historie av endringene dine. Dette er viktig hvis du skulle trenge å gå tilbake til gamle commits senere.
4. Når du har gjort deg ferdig for dagen og ønsker å ha med de siste endringene dine med i den siste versjonen av prosjektet, må du flette inn endringene dine i master branchen som ligger på nettet. Men det kan være lurt å få noen til å se gjennom endringene før du merger. På GitHub og GitLab kan du sende en forespørsel på at du ønsker å merge en branch til remote master (master branchen som ligger på nettsiden og ikke lokalt på PC-en). På GitHub kalles dette for en 'pull request' og på GitLab kalles det 'merge request'. Begge gjør det samme; spør om tillatelse på en merge. Trykk på drop down menyen under for å se en mer detaljert guide på hvordan du kan lage en pull request på GitHub.
%% Cell type:markdown id: tags:
### Hvordan lage en pull request på GitHub
%% Cell type:markdown id: tags:
Før du kan gjøre en pull request, må du sørge for at du pusher selve branchen du ønsker å merge på GitHub. Bruk kommandoen `git push origin <branch>` til dette og erstatt `<branch>`med navnet på branchen din.
For å lage en pull request på GitHub, må du trykke på "Pull Request" og deretter "create a pull request". Disse knappene er markert på skjermbildet under:
<imgsrc = 'img/pull_request.png'width = 600px>
Når du har trykket på "create a pull request", blir du tatt i en ny side der du må velge den branchen du ønsker å merge fra. Du velger hvilken branch du vil merge fra ved å trykke på drop down menyen som er sirklet i bildet under. Den valgte branchen til høyre, altså basen, er den du forespør å merge til. Oftest bruker man master som base branchen. Deretter må du trykke på 'Create pull request' som er markert i bildet under. På bildet ser du at du får en tilbakemelding fra GitHub om handlingen er trygg. I dette tilfellet er det en trygg handling fordi det står "Able to merge". Hadde det oppstått en merge konflikt, så ville det ikke stått "Able to merge".
Da kan du skrive tittel på forespørselen og en beskrivelse av hva du prøver å merge, hvis du ønsker. På samme side kan du velge hvem som skal vurdere pull requesten din under "Reviewers". Et skjermbilde av siden som kommer opp etter at du har trykket på "Create a pull request" er vist under.
Til nå har vi sett på hvordan vi bruker Git fra en terminal (powershell på Windows, terminalen på Linux og Mac). Det er viktig å forstå hvordan man bruker det, men det finnes også programmer som tilbyr grafisk visualisering av Git. Disse kan du bruke i stedet for å skrive git kommandoer i terminalen, men heller trykke på knapper. Slike programmer kan være mer brukervennlige for nybegynnere i Git. Disse tilbyr ofte god visualisering av ulike Git konsepter slik som commits, branches, staging, merge osv. Det kan også være et enklere verktøy å bruke til å løse potensielle merge conflicts og tydelig se hva hver Git kommandoer i praksis gjør.
Vi skal se på GitKraken som et eksempel i guiden under, som per juli 2020 har pro versjonen gratis for studenter som registrerer seg på GitHub som student. GitKraken fungerer for hvilken som helst operativsystem. Merk at dette er et kommersielt program, og om du velger å bruke det er helt valgfritt. Det finnes også andre gratis open-source løsninger, en oversikt over disse finner du ved å trykke [her](https://acodez.in/git-gui-clients/). Prinsippet er ofte det samme, fordi de alle er basert på Git. Hvilket program som er best for deg vil avhenge av operativsystem. [Denne linken her](https://acodez.in/git-gui-clients/) gir en beskrivelse av de opplistede GUI programmene for Git.
Vi skal se på GitKraken som et eksempel i guiden under, som per juli 2020 har pro versjonen gratis for studenter som registrerer seg på GitHub som student. GitKraken fungerer for hvilken som helst operativsystem. Merk at dette er et kommersielt program, og om du velger å bruke det er helt valgfritt. Det finnes også andre gratis open-source løsninger, en liste over forslag til programmer som tilbyr GUI for Git og beskrivelse av disse finner du f.eks [her](https://acodez.in/git-gui-clients/). Prinsippet er ofte det samme, fordi de alle er basert på Git. Hvilket program som er best for deg vil avhenge av operativsystem.
Det er også verdt å nevne at noen store IDEer (Integrated Development Environment, på norsk: grafiske utviklingsgrensesnitt) har Git integrert slik at du kan bruke Git direkte i IDEen du skriver kode i direkte. Eksempler på disse er Pycharm og IntelliJ. Det anbefales at du setter deg inn i hvordan du bruker Git i den IDEen du jobber i.
Om du ønsker å følge videoen under og komme i gang med GitKraken, må du først lage en GitHub bruker som student hvis du ikke har gjort det enda. Trykk [her](https://education.github.com/students) og videre på knappen 'Get benefits for students'. Sørg for å bruke NTNU-mailen din når du registerer deg som student.
Last deretter ned GitKraken ved å trykke [her](https://www.gitkraken.com/download)
%% Cell type:markdown id: tags:
## Kort introduksjon til GitKraken
%% Cell type:markdown id: tags:
Først må du åpne et prosjekt som ligger på PC-en din og som inneholder en git repository. Dette kan gjøres på flere måter:
1. Du kan åpne et prosjekt som enten allerede er klonet fra en remote repository (som f.eks GitHub) til PC-en din, eller et prosjekt som du allerede har en lokal git repo på PC-en. Uansett om prosjektet er klonet eller har en lokal git repo, kan du åpne dette med å først trykke på 'Open a repo' markert i bildet under
<img src = 'img/open_repo.png' width = 600px>
og deretter trykke 'Open a Repository' markert på bildet under.
Videre kan du velge prosjektet ditt fra filutforsker/finder som dukker opp.
2. Alternativt kan du klone et prosjekt fra en remote repository direkte i GitKraken. Da velger du alternativet, 'Clone a repo' i stedet som er markert i figuren under.
<imgsrc = 'img/clone_repo.png'width = 600px>
På det nye vinduet som dukker opp, kan du velge hvilken mappe du vil klone *til* og gi den URL-en til nettsiden du vil klone *fra* i feltene vist i bildet under.
<img src = 'img/git_clone.png' width = 600px>
3. Gitt en mappe med kodefiler som ligger lokalt på PC-en din som du ønsker å lage en git repo på, kan du velge alternativet 'Start a local repo' i stedet markert i bildet under.
<imgsrc = 'img/local_repo.png'width = 600px>
Denne gjør samme jobben som kommandoen, `git init` gjør. Da lager du et git repo lokalt på PC-en din og kan begynne å bruke git på kodefilene i den samme mappen. Men med dette alternativet, er du ikke koblet til en remote repo. Når du har trykket på 'Start a local repo' kan du velge mappen du ønsker å lage en lokal repo på ved å trykke på 'Browse' markert på bildet under.
4. Som siste alternativ, kan du velge å lage en remote repository på f.eks GitHub, GitLab eller en annen tjeneste direkte i GitKraken. Dette kan du gjøre ved å trykke en av tjenestene under 'Start a hosted repo' der du har valget mellom å hoste prosjektet ditt på GitHub, GitLab, Bitbucket eller Azure DevOps. Trykk på en av disse ønskede tjenestene markert i bildet under
Denne handlingen vil tilsvare kommandoen `git remote add origin <url>` og kobler deg opp til tjenesten direkte, slik at du slipper å lage en remote repo manuelt på nettjenesten (GitHub, GitLab etc.).
Bildet under viser vinduet som dukket opp da jeg valgte å koble til GitHub:
og du kan nå velge den mappen på PC-en din som du ønsker å koble til den remote repositorien ved å trykke på 'Browse' under 'Where to clone to' og velge tittel under 'Name'. Du må også velge konto og du må koble GitKraken til tjenesten om du ikke har gjort den enda.
I eksempelet her, har jeg åpnet en eksisterende repo som jeg også har koblet til GitHub:
Nå som den er åpnet, så ser vi at vi i midten har en trestruktur som viser hvilke commits som har blitt gjort, sammen med meldingen. Vi kan også se rundinger med ulike figurer, og om du holder over disse, ser du navnet til personen som gjorde committen. Vi ser også ulike grener og navnet på dem. I bildet over finnes det kun to grener; master og en som heter oving1. Du kan også se grener som ble flettet sammen med master grenen via en 'merge'. Grener er visualisert som utstikkere og du ser en merge ved at en utstikker går inn i en annen. I eksempelet over, har grenen, 'oving1', blitt flettet med master. Det står også en beskjed øverst i treet 'Merge branch oving1' som forteller at oving1 har blitt flettet inn i master.
Til høyre ser vi filer som har blitt endret siden forrige commit sammen med commit meldingen.
%% Cell type:markdown id: tags:
Ved å trykke på rundingene i treet, kan du se commit meldingene og endringer som har blitt gjort i høyre spalte. I høyre spalte, dukker filene opp som har blitt endret på, lagt til eller slettet. Filer som er lagt til får et grønt plusstegn foran, filer som har blitt slettet får et rødt minustegn foran og filer som har blitt endret på får blyant foran. Du kan trykke deg på hver enkel fil for å se en visualisering av endringer som har blitt gjort. GitKraken tilbyr en visualisering av differansen mellom filen før den ble endret og etter at den ble endret under 'Diff View'. Du kan også se filen i dens originale format under 'File View'. Slettede linjer i en fil er markert med rødt og linjer som er lagt til er markert med grønt. Kjør videoen under for å se demonstrasjon av dette.
Venstre spalte viser deg dine lokale og remote repoer. For å lage en branch fra master, høyretrykker du på 'master' i venstre spalte og deretter på 'Create branch here'. Gi den deretter et navn og trykk deretter på enter. Da vil det dukke opp enda en branch under 'Local'. Du bytter mellom branchene dine ved å dobbeltklikke på dem. Spill av videoen under for å se en demonstrasjon på dette.
Når det har blitt gjort en endring på prosjektet, signaliseres dette ved at det dukker opp en blyant øverst. Du kan se endringer som har blitt gjort ved å trykke på blyanten og da vil høyre spalte bli todelt der filene hvor det har blitt gjort endring på dukker opp under 'Unstaged files'. Du kan velge å trykke på filen for å få opp 'Diff View' igjen for å se hva som har blitt endret på siden sist. Deretter kan du 'stage' endringer ved å enten trykke på 'Stage file' når du holder musa over filen som er endret, eller 'Stage all changes'. Deretter kan du skrive en commit melding og trykke 'Commit'
Du kan flette en branch inn i en annen ved å 'merge'. Da må du stå i branchen du vil merge fra, høyreklikke på den branchen du vil merge til og deretter trykke på 'Merge branch1 into branch2' der branch1 og branch2 er de grenene du vil flette sammen. Videoen under viser hvordan du merger fra new_branch til master. For å publisere den siste versjonen av prosjektet som ligger lokalt på PC-en til remote repo, trykker du på 'Push'. Videoen under viser hvordan du pusher fra master til origin.
Du kan hente endringene fra remote repo ved å først trykke deg inn på den branchen du vil hente endringene dine til, og deretter trykke på 'Pull' i øverste linje. Videoen viser hvordan du henter endringene fra origin til master.
