Update README.md

README.md

-# Lecture Code
+# Lecture code
+
+## Norsk (<a href="#english">English below</a>)
+Dette repoet inneholder alle filene vi bruker/lager under forelesninger.
+Etter hver forelesning oppdateres prosjektet med de relevante filene.
+
+## Hvordan beholder jeg de lokale endringene mine når nye forelesningsnotater legges til dette repoet?
+Hvis du gjør endringer på dette repoet kan det oppstå konflikter hvis både du og foreleser har endre på de samme filene og du så prøver å pulle disse endringene for å oppdatere din klone av repoet.
+
+Hvordan du håndterer dette er avhengig av hva du har tenkt å gjøre med koden:
+* [Jeg vil gjøre endringer på koden og lagre disse i gitlab.](#1-lag-et-separat-prosjekt-med-endringer)
+* [Jeg vil gjøre endringer på koden men bare lagre dem lokalt.](#2-bruk-pull-og-håndter-endringer-manuelt)
+* [Jeg vil gjøre endringer på koden men ikke lagre dem.](#3-slett-klonen-og-klon-på-nytt)
+* [Jeg vil ikke gjøre endringer på koden.](#4-ikke-gjør-endringer)
+
+### 1. Lag et separat prosjekt med endringer
+1. Fork repoet og klon forken, eller klon dette repoet direkte.
+2. Lag ditt eget prosjekt som er tiltenkt endringer. Dette kan være et repo på gitlab som du kloner, eller det kan være bare en lokal mappe hvis du ikke har tenkt å lagre endringer i gitlab.
+3. Kopier over filene du ønsker fra din klone av lecture_code-repoet og lim dem inn i endrings-prosjektet. Disse kan nå pushes fritt uten problemer.
+4. Når du vil oppdatere ditt lecture_code repo, bruker du kommandoen `git pull` i terminalen for å pulle nye endringer fra lecture_code repoet. **Hvis du har laget ditt eget repo for endringer** går du nå inn i dette og trykke på knappen som sier "Update fork".
+5. Kopier over filene du ønsker inn i endrings-repoet ditt. Du har nå ingen konflikter og får beholde endringene dine uten problemer.
+
+### 2. Bruk pull og håndter konflikter manuelt
+**Hvis du vil pushe endringene dine til gitlab, bruk den forrige metoden. Denne metoden vil gjøre det vanskeligere.**
+
+Den forrige kommandoen bruke `git pull`. Ingen konflikter oppstår, fordi ingen endringer hadde blitt gjort på repoet før foreleser lastet opp ny kode. Disse endringene ble holdt i et separat prosjekt. **Hvis du ikke har tenkt å pushe endringene dine til git, kan du spare deg selv for å kopiere filer ved å bare bruke `git pull` og så manuelt håndtere konflikter**. Når du puller filer som lager konflikt, må du gjøre en av to ting først:
+
+#### Commit eller stash
+Å bruke **Commit** burde vært kjent fra før. Dette er det vi gjør før vi kan pushe endringer til gitlab repoet vårt.
+
+1. **Hvis du forket dette repoet**, gå inn i forken og trykk knappen som sier "Update fork" først.
+2. Lagre alle filene du gjorde endringer på lokalt i din IDE.
+3. Bruk kommandoen `git add .` i terminalen for å "stage" endringene. (De fleste IDEer har innebygd funksjonalitet for å stage endringer.)
+4. Bruk kommandoen `git commit -m "YOUR COMMENT HERE" for å commite endringene. **IKKE PUSH**. Dette kan forårsake mange problemer. Hvis du vil pushe koden, bruk metoden over.
+5. Bruk kommandoen `git pull` for å hente endringene fra lecture_code repoet. Konflikter kan oppstå her, og du må manuelt velge hvilken versjon du ønsker å beholde.
+
+Å **stashe** betyr å "legge vekk" de lokale endringene så du kan jobbe på andre ting og hente endringene tilbake når du trenger dem. Denne metoden gjør i dette tilfellet akkurat det samme som å commite (merk at disse kommandoene ikke er ekvivalente).
+
+1. **Hvis du forket dette repoet**, gå inn i forken og trykk knappen som sier "Update fork" først.
+2. Lagre alle filene du gjorde endringer på lokalt i din IDE.
+3. Bruk kommandoen `git stash` i terminalen din for å stashe vekk endringene.
+4. Bruk kommandoen `git pull` i terminalen for å hente endringene fra lecture_code repoet.
+5. Bruk kommandoen `git stash pop` for å hente frem igjen endringene du stashet. Konflikter kan oppstå her, og du må manuelt velge hvilken versjon du ønsker å beholde. **IKKE PUSH**. Dette kan forårsake mange problemer. Hvis du vil pushe koden, bruk metoden over.
+
+### 3. Slett klonen og klon på nytt
+**Hvis du ikke føler for å beholde endringene du har gjort på forelesningskoden**, kan du enkelt nok slette klonen din og klone når nye endringer lastes opp. Så kan du klone prosjektet på nytt og ta det derfra.
+
+Eventuelt kan du slette alle endringene du har gjort og bruker kommadoen `git pull` i terminalen, men om du ikke er nøyaktig og sletter alle endringer, kan det oppstå konflikter.
+
+### 4. Ikke gjør endringer
+**Hvis du ikke har tenkt å gjøre endringer på forelesningskoden**, men du vil ha prosjektet lokalt, vil det ikke oppstå konflikter og du kan bare bruke kommandoen `git pull` i terminalen for å oppdatere klonen din (eller bruke metode 3).
+
+---
+## English
 This repository contains all files we use/make during lectures.
 After each lecture we will update the project with the relevant files.
 
-## How do I keep my local changes when new lecture notes are added to this file?
+## How do I keep my local changes when new lecture notes are added to this repository?
 If you make changes to this repo, there might become conflicts if both you and the lecturer have changed the same files, and you then try to pull these changes to update your clone of the repo.
 
-It all depends on what you intend to do with the code:
-* [I want to make changes to the code and store these in gitlab.](#1-create-a-separate-project-with-changes)
+How to handle this depends on what you intend to do with the code:
+* [I want to make changes to the code and store them in gitlab.](#1-create-a-separate-project-with-changes)
 * [I want to make changes to the code but only store them locally.](#2-use-pull-and-manually-deal-with-conflicts)
 * [I want to make changes to the code but not store them.](#3-delete-the-clone-and-re-clone)
 * [I don't want to make changes to the code.](#4-dont-make-changes)
@@ -14,7 +67,7 @@ It all depends on what you intend to do with the code:
 
 ### 1. Create a separate project with changes
 1. Fork and clone or directly clone this repo.
-2. Create your own project that is intended for changes. This can be a repo on gitlab that you clone, or it can be just a local file if you don't intend on storing it on gitlab.
+2. Create your own project that is intended for changes. This can be a repo on gitlab that you clone, or it can be just a local folder if you don't intend on storing it on gitlab.
 3. Copy over the files you want from your clone of the lecture_code-repo, and paste them into the change-repo. You can push these freely if you created a repo.
 4. When you want to update your lecture_code repo, use the command ``git pull`` in your terminal to pull new changes from the lecture_code repo. **If you created your own repo**, go into this repo on gitlab and press the button that says "Update fork" first.
 5. Copy over the update files you want into your change-repo. You now have no conflicts and get to keep your own changes without problem.
@@ -40,7 +93,7 @@ The previous method used the command ``git pull``. No conflicts arose, because n
 5. Use the command ``git stash pop`` to reinstate your local changes. Conflicts might arise here, and you have to manually choose if you want to keep one version of the file or both versions. **DO NOT PUSH**. This may cause a lot of issues. If you want to push changes, use the method above.
 
 ### 3. Delete the clone and re-clone
-**If you don't feel the need to keep your changes to the lecture code**, you can simply delete your clone whenever new updates are added. Then, you can clone the project over again and take it from there.
+**If you don't feel the need to keep your changes to the lecture code**, you can simply delete your clone whenever new updates are added. Then, you can clone the project over again and take it from there. 
 
 ### 4. Don't make changes
 **If you don't intend on making any changes to the lecture code**, but you want to have a local save, there will be no conflict issues and you can just use ``git pull`` in your terminal to update your clone (or use method 3).