Sessie 11: Git: Jouw code-geschiedenisboek

Stel je voor: je werkt drie uur aan je game. Je voegt een cool nieuw wapen toe. Maar… nu doet de rest van je game het niet meer. En je weet niet meer wat je precies veranderd hebt. Weg drie uur werk.

Git is de oplossing. Git onthoudt élke versie van je bestanden. Als een oneindige “undo”-knop die nooit vergeet wat je gedaan hebt.

In deze sessie installeer je Git, maak je je eerste repository en leg je voor altijd vast wat je doet: stap voor stap, versie voor versie. En het leuke: Git werkt niet alleen voor code. Ook voor notities, schoolverslagen en verhalen.

Wat is Git?

Git is een versiebeheersysteem. Het houdt bij wat jij verandert in je bestanden, wanneer je dat deed, en waarom. Elke keer dat je een stukje werk af hebt, maak je een commit: een foto van al je bestanden op dat moment.

Wat Git bijzonder maakt:

• Elke versie is bewaard. Je kunt altijd terug naar een vorige commit als iets kapot gaat.
• Je werkt lokaal. Git draait op jouw computer. Geen internet nodig.
• Git is snel. Zelfs projecten met duizenden bestanden controleren in milliseconden.

Git is gemaakt door Linus Torvalds, dezelfde persoon die Linux bouwde. Hij had iets nodig om met duizenden programmeurs tegelijk aan de Linux-kernel te werken. In 2005 bouwde hij Git in een weekend. Vandaag gebruikt bijna elke ontwikkelaar ter wereld het.

Git is niet alleen voor code

Git is gebouwd voor broncode, maar het werkt met alle tekstbestanden. Een tekstbestand is elk bestand dat je met Kladblok of een simpele editor kunt openen en lezen: .py, .html, .css, .json, .txt, .csv, .md (Markdown), .yml, .toml, noem maar op.

Wat Git níet goed kan: binaire bestanden. Dat zijn bestanden die niet uit leesbare tekst bestaan: afbeeldingen (.png, .jpg), video’s (.mp4), gecompileerde programma’s (.exe), Word-documenten (.docx). Git kan ze wél bijhouden, maar het is trager en je kunt niet zien wát er precies veranderd is. Bij tekstbestanden toont git diff elke letter die je toevoegde of weghaalde. Bij een .png zegt Git alleen “dit bestand is gewijzigd”, maar niet wát er aan de afbeelding veranderde.

Markdown en notities

Veel notitie-apps van tegenwoordig gebruiken Markdown (.md-bestanden) om je documenten op te slaan. Denk aan:

• Obsidian: je notities zijn gewoon .md-bestanden in een map op je computer
• Notion: exporteert naar Markdown
• Joplin: slaat alles op als Markdown
• Typora, Zettlr, Logseq: allemaal Markdown-gebaseerd

Omdat Markdown-bestanden gewone tekstbestanden zijn, kun je er Git op loslaten. Je houdt de geschiedenis van je notities bij, je kunt terug naar een vorige versie van een document, en je kunt je notities delen via GitHub, precies zoals je met code doet.

Een map met Markdown-notities onder Git zetten is even simpel als een Python-project:

mkdir mijn-notities
cd mijn-notities
git init
echo "# Mijn Notities" > start.md
git add start.md
git commit -m "Eerste notitie: startpagina"

Vanaf dat moment bewaart Git elke wijziging aan je notities. Schrijf je een verslag voor school in Markdown? Commit elke paragraaf. Werk je aan wereldbouw voor een verhaal? Git onthoudt elke versie van je plot.

Wanneer Git wél en níet voor notities gebruiken

Kortom: alles wat tekst is, kun je in Git stoppen. Alles wat binair is, beter niet.

Waarom versiebeheer?

Zonder Git ziet je workflow er zo uit:

game.py
game_backup.py
game_backup2.py
game_final.py
game_final_echt.py
game_final_echt_nieuwe_wapens.py

Herkenbaar? Met Git heb je maar één bestand nodig: game.py. Git onthoudt de rest.

Wat versiebeheer je oplevert:

• Nooit meer werk kwijt. Alles wat je commit, blijft bestaan. Altijd.
• Begrijpen wat er gebeurd is. Je ziet exact welke regels je wanneer veranderde.
• Experimenteren zonder risico. Maak een aparte kopie van je code (een branch), probeer iets geks, en gooi het weg als het niet werkt. Je originele code blijft intact.
• Samenwerken. Meerdere mensen kunnen tegelijk aan hetzelfde project werken, zonder elkaars code te overschrijven.

Wat stop je NIET in Git?

Git is gemaakt voor tekstbestanden: bestanden die jij zelf schrijft: code, notities, configuratie. Er zijn dingen die je beter buiten Git houdt:

Waarom geen wachtwoorden in Git? Omdat Git álles onthoudt, voor altijd. Zelfs als je later een wachtwoord verwijdert, zit het nog in de geschiedenis. Iedereen die jouw code ooit ziet, kan terugscrollen naar die commit. En als je code ooit op GitHub komt, staat je wachtwoord op het internet. Voor eeuwig.

Gebruik een .gitignore-bestand om Git te vertellen welke bestanden het moet negeren. Daar kom je zo meteen achter.

Stap 0: Git installeren

Windows

1. Ga naar git-scm.com en download de Windows-installer.
2. Dubbelklik het gedownloade bestand.
3. Klik door de installatie. De standaardopties zijn prima.
4. Belangrijk: kies bij het kiezen van de teksteditor Nano of Notepad++ (niet Vim, tenzij je Vim al kent).
5. Open na de installatie Git Bash (zoek ernaar in het startmenu).

Mac

Open de Terminal (zoek naar “Terminal” in Spotlight) en typ:

git --version

Als Git niet geïnstalleerd is, vraagt macOS je om de developer tools te installeren. Klik op “Install”. Klaar.

Linux (Ubuntu/Debian)

sudo apt install git

Controleren of het werkt

Open een terminal (Git Bash op Windows) en typ:

git --version

Je ziet iets als git version 2.47.0. Dat betekent: Git staat klaar.

Stap 1: Vertel Git wie je bent

Git wil weten wie jij bent, zodat het jouw naam bij elke commit kan zetten. Dit doe je één keer, daarna onthoudt Git het.

git config --global user.name "Jouw Naam"
git config --global user.email "jouw@email.com"

Gebruik hetzelfde e-mailadres dat je straks voor GitHub gebruikt. Dat maakt koppelen makkelijker.

Tip: --global betekent: deze instelling geldt voor ál je Git-projecten. Je hoeft dit maar één keer te doen.

Stap 2: Je eerste repository maken

Een repository (of “repo”) is een map waar Git de versies bijhoudt. Laten we er één maken.

Maak eerst een nieuwe map voor je project:

mkdir mijn-eerste-git-project
cd mijn-eerste-git-project

Nu vertel je Git: “Deze map is een repository.”

git init

Je ziet: Initialized empty Git repository in .../mijn-eerste-git-project/.git/

Git heeft een verborgen map .git aangemaakt. Daar bewaart het álles: de geschiedenis, de commits, de configuratie. Raak die map nooit met de hand aan, want Git beheert hem zelf.

Stap 3: Je eerste bestand committen

Maak een bestand aan. Bijvoorbeeld een Python-bestand met één regel:

echo 'print("Hallo Git!")' > hallo.py

Nu vertel je Git: “Let op dit bestand.”

git add hallo.py

Met git add zet je bestanden in de staging area: een tussenstation. Je zegt tegen Git: “Deze wijzigingen wil ik in mijn volgende commit.”

Controleer wat er klaarstaat:

git status

Git toont:

On branch master
Changes to be committed:
  new file:   hallo.py

Nu komt de commit zelf:

git commit -m "Mijn eerste commit: hallo.py toegevoegd"

Wat gebeurt hier? -m staat voor “message”. De tekst tussen aanhalingstekens is je commit message: een korte uitleg van wat je veranderd hebt. Git heeft nu een permanente foto van je project gemaakt.

Goede commit messages: Schrijf in het Engels (dat is de afspraak in bijna alle projecten). Begin met een werkwoord: “Add”, “Fix”, “Update”. Hou het kort: maximaal 72 karakters.

Stap 4: Veranderingen bijhouden

Open hallo.py in een teksteditor. Verander de regel naar:

print("Hallo Git! Jij onthoudt mijn code.")

Sla het bestand op. Kijk nu wat Git ziet:

git status

Git weet dat hallo.py gewijzigd is. Maar wát is er precies veranderd?

git diff

git diff toont exact welke regels je toegevoegd (groen met +) en verwijderd (rood met -) hebt. Dit is één van de krachtigste dingen van Git: je ziet letterlijk wat er veranderd is, karakter voor karakter, sinds je laatste commit.

Commit de wijziging:

git add hallo.py
git commit -m "Update: begroeting uitgebreid"

Stap 5: Terug in de tijd

Dit is waar Git magisch wordt. Stel: je hebt spijt van je laatste wijziging. Je wilt terug naar de eerste versie.

Toon eerst alle commits:

git log --oneline

Je ziet zoiets:

a1b2c3d Update: begroeting uitgebreid
e4f5g6h Mijn eerste commit: hallo.py toegevoegd

Elke commit heeft een unieke code, een hash. Die lange code (verkort tot 7 karakters) identificeert exact die ene versie van je project.

Om te zien hoe hallo.py eruitzag in de eerste commit:

git show e4f5g6h:hallo.py

Daar is je originele print("Hallo Git!") weer.

Wil je écht terug in de tijd? Dat kan:

git checkout e4f5g6h -- hallo.py

Nu staat hallo.py weer zoals in je eerste commit. Controleer met cat hallo.py. Je ziet de oude versie. Maar maak je geen zorgen: je tweede commit is niet weg. Met git checkout master -- hallo.py ga je weer naar de nieuwste versie.

Stap 6: Wat níet in Git: .gitignore

Maak een bestand aan dat Git moet negeren:

echo "GEHEIM_WACHTWOORD=12345" > geheimen.txt

git status toont dit bestand nu als “untracked”. Git heeft het gezien, maar weet niet of je het wilt bijhouden. Je kunt het negeren met een .gitignore-bestand:

echo "geheimen.txt" > .gitignore

Nu git status opnieuw en geheimen.txt is verdwenen uit de lijst. Git negeert het. (Voeg .gitignore zelf wél toe aan Git met git add .gitignore en git commit, zodat anderen ook weten wat er genegeerd moet worden.)

Een goed .gitignore voor een Python-project:

# Python
__pycache__/
*.pyc
*.pyo

# Geheimen
*.env
secrets.txt

# Jouw editor
.vscode/
.idea/

Showcase

Laat aan een coach en een buddy zien:

1. Je repository met minstens 3 commits.
2. Het resultaat van git log --oneline: jouw commit-geschiedenis.
3. Een git diff die toont wat je veranderd hebt.
4. Je .gitignore-bestand.

Tot de volgende keer!

“Volgende keer: twee versies van je code tegelijk. Je werkt aan een nieuwe feature terwijl de oude versie gewoon blijft werken. Dat heet branches, en het is wat Git écht krachtig maakt.”

Neem mee naar huis

1. Makkelijk: Maak een repository voor je notities. Zet een Markdown-bestand met wat je vandaag geleerd hebt in Git, en commit het.
2. Middel: Verander iets in je code of notities, gebruik git diff om de wijziging te bekijken, en commit hem met een goede message.
3. Lastig: Maak drie commits met verschillende wijzigingen. Gebruik git show om elke versie te bekijken. Gebruik git checkout om terug te gaan naar de eerste commit, en daarna weer naar de laatste.
4. Erg lastig: Maak een Python-project met een goede .gitignore. Zorg dat __pycache__/ en .pyc-bestanden écht genegeerd worden (check met git status).

Vastgelopen? Vraag het volgende dojo aan een coach, of probeer gewoon iets anders. Programmeren is doen. Git leren is doen.

Sessie 12: Git Branches: Parallelle universums voor je code

Vorige sessie leerde je commits maken: foto’s van je code op één tijdlijn. Alles netjes achter elkaar.

Maar wat als je een nieuw idee wil uitproberen? Een lasergun toevoegen aan je game, bijvoorbeeld. Je weet niet of het gaat werken. Je wil je werkende code niet kapot maken.

Daar zijn branches voor.

Een branch is een kopie van je code waar je vrij kunt experimenteren. Je hoofdcode (de master-branch) blijft veilig. Als je experiment werkt, plak je het terug in master. Werkt het niet? Je gooit de branch weg. Je master-branch heeft er nooit iets van gemerkt.

Noot: Op GitHub en in veel nieuwe projecten heet de hoofdbranch main in plaats van master. Dat is exact hetzelfde, alleen de naam is anders. In deze cursus gebruiken we master, maar als je online main tegenkomt, weet je dat het hetzelfde betekent.

Wat je vandaag leert

• Wat een branch is en hoe Git branches intern opslaat
• Branches aanmaken, wisselen en samenvoegen
• Wat een merge conflict is en hoe je het oplost
• Wanneer je wél en níet een branch moet gebruiken

Stap 0: Herhaling: waar sta je nu?

Open je terminal in het project van vorige sessie. Check waar je bent:

git status
git log --oneline

Je hebt een paar commits op master. Dit is je stabiele basis: hier ga je straks vanaf splitsen.

Stap 1: Je eerste branch

Je gaat een nieuwe feature toevoegen: een highscore.txt-bestand dat de hoogste score bijhoudt. Maar eerst maak je een branch:

git branch highscore-feature

Git heeft nu een nieuwe branch aangemaakt. Maar je staat nog steeds op master. Check welke branches er zijn:

git branch

Je ziet:

  highscore-feature
* master

Het sterretje bij master betekent: “hier sta je nu.” Wissel naar je nieuwe branch:

git switch highscore-feature

(Oudere Git-versies gebruiken git checkout highscore-feature. Beide werken.)

Nog een keer git branch: het sterretje staat nu bij highscore-feature. Alles wat je nu commit, gebeurt op deze branch. master blijft onaangeroerd.

Tip: Je kunt een branch aanmaken en er meteen naartoe switchen in één commando:

git switch -c mijn-nieuwe-branch

-c staat voor “create”. Dit is sneller en je vergeet nooit te switchen.

Stap 2: Werk doen op een branch

Maak een nieuw bestand aan:

echo "HIGHSCORE: 0" > highscore.txt

Commit je werk:

git add highscore.txt
git commit -m "Add highscore.txt met beginwaarde 0"

Voeg nog een bestand toe dat de highscore leest:

echo 'def lees_highscore():' > highscore_manager.py
echo '    with open("highscore.txt") as f:' >> highscore_manager.py
echo '        return int(f.read().split(": ")[1])' >> highscore_manager.py

Commit opnieuw:

git add highscore_manager.py
git commit -m "Add highscore_manager: functie om highscore te lezen"

Kijk nu naar je log:

git log --oneline

Je ziet al je commits van master, plus de twee nieuwe. Git onthoudt de hele keten.

Stap 3: Twee werelden tegelijk

Switch terug naar master:

git switch master

Kijk wat er hier is:

ls

highscore.txt en highscore_manager.py zijn… weg. Ze bestaan alleen op de highscore-feature-branch. Op master is alles nog precies zoals je het achterliet.

Dit is de magie van branches: twee (of meer) versies van je project, tegelijk op je computer, zonder dat ze elkaar in de weg zitten.

Switch nog eens heen en weer om het te voelen:

git switch highscore-feature   # bestanden zijn terug
git switch master                # bestanden zijn weer weg

Stap 4: Samenvoegen met git merge

Je highscore-feature werkt. Tijd om hem terug in master te zetten. Dit heet mergen.

Zorg dat je op master staat:

git switch master

Voeg de branch samen:

git merge highscore-feature

Git toont iets als Updating a1b2c3d..e4f5g6h en Fast-forward. Je highscore-feature-commits zijn nu onderdeel van master. Controleer:

ls
git log --oneline

highscore.txt en highscore_manager.py staan nu op master. Alle commits van de feature-branch zijn opgenomen in de geschiedenis.

Stap 5: Wat zijn merge conflicts?

Stel: je hebt op master iets veranderd in highscore.txt, bijvoorbeeld “HIGHSCORE: 100” in plaats van “HIGHSCORE: 0”. En tegelijkertijd heb je op een andere branch highscore.txt ook veranderd, naar “HIGHSCORE: 500”.

Als je nu probeert te mergen, weet Git niet welke versie de juiste is. Dat is een merge conflict. Git vraagt jóu om te beslissen.

Laten we het expres uitlokken.

Op master:

echo "HIGHSCORE: 100" > highscore.txt
git add highscore.txt
git commit -m "Update highscore naar 100 op master"

Maak een nieuwe branch en verander daar hetzelfde bestand:

git switch -c andere-highscore
echo "HIGHSCORE: 500" > highscore.txt
git add highscore.txt
git commit -m "Update highscore naar 500"

Switch terug naar master en probeer te mergen:

git switch master
git merge andere-highscore

Git zegt: CONFLICT (content): Merge conflict in highscore.txt. Open highscore.txt in je editor. Je ziet:

<<<<<<< HEAD
HIGHSCORE: 100
=======
HIGHSCORE: 500
>>>>>>> andere-highscore

Dit zijn de twee versies. HEAD is jouw master-versie. Daaronder staat de versie van andere-highscore. Jij kiest welke je houdt, of je combineert ze.

Verwijder de markers en kies één versie:

HIGHSCORE: 500

Sla het bestand op. Vertel Git dat het conflict is opgelost:

git add highscore.txt
git commit -m "Merge: highscore van andere-highscore gekozen"

Conflict opgelost. Git kan weer verder.

Stap 6: Branches opruimen

Je feature is gemerged. De branch heb je niet meer nodig:

git branch -d highscore-feature
git branch -d andere-highscore

-d staat voor “delete”. Git weigert een branch te verwijderen die nog niet gemerged is: dat is een veiligheidsklep. Als je écht weg wil gooien zonder mergen, gebruik je -D (hoofdletter). Maar wees daar voorzichtig mee.

Wanneer wél een branch, wanneer niet?

Vuistregel: Als je twijfelt, maak een branch. Een branch kost niks. Code kwijtraken wel.

Tips om vlot te werken met branches

1. Houd branches kort. Een branch van 3 uur is prima. Een branch van 3 weken wordt een merge-nachtmerrie: hoe langer je wacht met mergen, hoe meer er intussen op master verandert, en hoe groter de kans op conflicts.
2. Eén ding per branch. “Highscore toevoegen” is een goede branch. “Highscore, menu, en nieuwe levels toevoegen” is te veel: split het op.
3. Merge vaak. Werk je feature af, merge hem meteen terug naar master. Kleine, frequente merges zijn makkelijker dan één groot monster-merge.
4. Geef branches duidelijke namen. highscore-feature is goed. test123 of branch2 zijn slecht. Over een week weet je niet meer wat er in test123 zat.
5. Check waar je bent voor je begint. git branch of git status vertelt je op welke branch je staat. Maak hier een gewoonte van, zodat je voorkomt dat je per ongeluk op master code schrijft die eigenlijk op een feature-branch hoort.

Showcase

Laat aan een coach en een buddy zien:

1. git branch met minstens twee branches (waaronder master).
2. Op elke branch een ander bestand of andere code.
3. Switch heen en weer: de bestanden verschijnen en verdwijnen.
4. Een succesvolle merge van een feature-branch in master.

Tot de volgende keer!

“Tot nu toe leeft al je code alleen op jouw laptop. Volgende keer zetten we hem online. Je maakt een GitHub-account, pusht je repository naar het internet, en je game is overal ter wereld te bekijken. En: je kunt samenwerken met anderen. GitHub: je code de wereld in.”

Neem mee naar huis

1. Makkelijk: Maak een branch voor een kleine feature in een bestaand project. Commit je werk en merge hem terug.
2. Middel: Creëer expres een merge conflict (twee branches die hetzelfde bestand wijzigen) en los het op.
3. Lastig: Werk met drie branches tegelijk op hetzelfde project. Merge ze één voor één terug in master. Check na elke merge of alles nog werkt.
4. Erg lastig: Maak een branch, commit drie wijzigingen, switch terug naar master, maak daar óók een wijziging in hetzelfde bestand, en merge de branch. Los het conflict zorgvuldig op en check met git log --graph hoe de geschiedenis eruitziet.

Sessie 13: GitHub: Je code online, voor iedereen

Tot nu toe leeft al je code op jouw laptop. Handig voor jou, maar niemand anders kan erbij. En als je laptop crasht, ben je alles kwijt.

GitHub is een website waar je Git-repositories online zet. Het is een back-up, een portfolio, en een samenwerkingsplatform in één. Vandaag zet je jouw code op GitHub. Aan het einde van deze sessie kan iedereen met een internetverbinding jouw projecten bekijken, en jij die van hen.

Wat is GitHub?

GitHub is niet hetzelfde als Git. Git is het versiebeheersysteem dat op jouw computer draait. GitHub is een website (github.com) die Git-repositories host: een soort Google Drive voor code, maar dan met Git eronder.

Wat GitHub toevoegt aan Git:

• Back-up in de cloud. Je code staat niet alleen lokaal. Laptop kapot? Je code overleeft.
• Samenwerken. Meerdere mensen kunnen aan dezelfde repo werken. GitHub regelt wie wat mag.
• Pull requests. Je vraagt toestemming om jouw wijzigingen in iemands project te stoppen, met discussie en review.
• Issues. Bugs melden, features voorstellen, taken bijhouden: allemaal in je repo.
• Portfolio. Je GitHub-profiel is je visitekaartje. Werkgevers kijken ernaar.

GitHub is niet de enige optie; er zijn alternatieven zoals GitLab en Bitbucket. Maar GitHub is de grootste, met meer dan 100 miljoen gebruikers. In deze sessies gebruiken we GitHub.

Stap 0: Een GitHub-account maken

1. Open github.com in je browser.
2. Klik op Sign up.
3. Vul je e-mailadres in. Gebruik hetzelfde adres dat je in sessie 11 bij git config hebt ingesteld: dat scheelt gedoe.
4. Kies een username. Dit wordt jouw identiteit op GitHub. Kies iets dat je over 5 jaar nog steeds leuk vindt. Je kunt je username later veranderen, maar oude links naar jouw profiel werken dan niet meer.
5. Verifieer je account via de e-mail die GitHub stuurt.
6. Kies het Free-abonnement. Alles wat je nodig hebt is gratis: onbeperkt publieke en private repositories.

Tip voor coaches: check of de ninjas toegang hebben tot hun e-mail tijdens de sessie. Sommige laptops staan niet ingelogd op webmail. Zorg voor een plan B: als e-mailverificatie niet lukt, kunnen ninjas GitHub later thuis verifiëren. De rest van de sessie werkt ook zonder verificatie.

Stap 1: Je eerste repository op GitHub

Je hebt een lokaal project op je computer (van sessie 11). Die ga je nu online zetten.

Op GitHub, klik rechtsboven op het + icoontje → New repository.

Vul in:

Klik Create repository.

GitHub toont nu instructies. Kies het blok onder "…or push an existing repository from the command line". Kopieer die drie commando’s: die heb je zo nodig.

Stap 2: Je lokale repo koppelen aan GitHub

In je terminal (in je projectmap):

git remote add origin https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git

Wat gebeurt hier? remote is een externe locatie waar jouw repo ook staat. origin is de naam die je die locatie geeft. “origin” is de standaardnaam voor je belangrijkste remote. Je kunt meerdere remotes hebben (bijvoorbeeld origin voor GitHub, backup voor GitLab), maar één is meestal genoeg.

Controleer of het gelukt is:

git remote -v

Je ziet:

origin  https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git (fetch)
origin  https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git (push)

fetch = hier haal je code vandaan. push = hier stuur je code naartoe. Meestal zijn die hetzelfde.

Stap 3: Je code online zetten met git push

Nu komt het moment: je lokale commits naar GitHub sturen.

git push -u origin master

push = stuur mijn commits naar de remote. -u origin master = “onthoud dat master op mijn computer hoort bij master op origin.” De volgende keer kun je gewoon git push typen, want Git onthoudt de koppeling.

GitHub vraagt om in te loggen. Dat kan op twee manieren:

1. Via de browser: GitHub opent een browservenster, je klikt op “Authorize”. Klaar.
2. Met een Personal Access Token: maak je aan via GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic). Geef de token een naam, vink repo aan, kopieer de token, en plak hem als wachtwoord in de terminal.

Voor ninjas: methode 1 (browser) is het makkelijkst. Als dat niet werkt, help dan met een token.

Na een succesvolle push, ververs je GitHub-pagina. Je bestanden staan er! Je hallo.py, je commit-geschiedenis: alles.

Stap 4: Wijzigingen pushen

Maak een wijziging lokaal:

echo 'print("GitHub is cool!")' >> hallo.py
git add hallo.py
git commit -m "Add GitHub enthusiasm"

Push naar GitHub:

git push

Je hoeft nu geen -u origin master meer, want Git weet de weg. Ververs GitHub: je nieuwe commit staat erbij.

Stap 5: Een nieuw project starten via GitHub

Dit is de omgekeerde route: je begint op GitHub en haalt het naar je computer.

Op GitHub: New repository. Noem hem python-spelletje. Vink dit keer wél Add a README file aan; GitHub maakt dan een repo met één bestand erin. Klik Create repository.

Nu haal je deze repo naar je computer. Dit heet clonen:

cd ~   # ga naar je home-map
git clone https://github.com/JOUW_USERNAME/python-spelletje.git

GitHub maakt een map python-spelletje aan met de README erin. En het is meteen een volwaardige Git-repository: de .git-map zit er al in. Je hoeft geen git init te doen.

cd python-spelletje
git log --oneline   # je ziet de eerste commit die GitHub voor je maakte

Nu kun je hier lokaal verder werken en je commits pushen naar GitHub, precies zoals in Stap 3 tot 4.

Stap 6: Wat als iemand anders ook wijzigingen maakt?

Stel: je hebt thuis aan python-spelletje gewerkt en gepusht. Nu ben je op de dojo-laptop en wil je verder. Je hebt de nieuwste versie nog niet.

git pull

git pull haalt de nieuwste commits van GitHub naar jouw computer. Het is twee acties in één: git fetch (ophalen) + git merge (samenvoegen met jouw lokale code).

Altijd git pull doen voor je begint met werken, anders loop je achter en krijg je merge conflicts.

Samenvatting van de workflow:

Onthoud: pull voor je begint, push als je klaar bent.

Showcase

Laat aan een coach en een buddy zien:

1. Je GitHub-profiel met minstens één repository.
2. De commit-geschiedenis van je repo op GitHub (klik op “X commits” boven de bestandslijst).
3. Een verse git push die net op GitHub is aangekomen.

Tot de volgende keer!

“Nu staat je code online. Maar wat zet je in een commit message? Hoe schrijf je een bericht dat over drie maanden nog steeds duidelijk is? En hoe werk je met een team zonder de boel te breken? Volgende keer: de professionele kant van Git: best practices die elke developer gebruikt.”

Neem mee naar huis

1. Makkelijk: Push een bestaand lokaal project naar een nieuwe GitHub-repository.
2. Middel: Maak 3 commits lokaal, push ze, en check op GitHub of ze allemaal zichtbaar zijn.
3. Lastig: Clone een repo van GitHub, maak een wijziging, commit, en push terug.
4. Erg lastig: Simuleer werken op twee computers: clone een repo, maak een commit en push. Ga naar een andere map, clone dezelfde repo opnieuw (alsof het een andere computer is), maak een andere commit, en probeer te pushen. Wat gebeurt er? Los het op met git pull.

Sessie 14: Git Best Practices: Schrijf commits die je later nog snapt

Je kunt Git-commando’s typen. Je code staat op GitHub. Maar er is een verschil tussen “Git gebruiken” en “Git goed gebruiken.”

Deze sessie gaat over de gewoontes die ervaren developers elke dag toepassen. Geen nieuwe commando’s, wel scherpere regels. Aan het einde schrijf je commit messages waar je over een jaar nog iets aan hebt, en werk je met een branching-strategie die je project overzichtelijk houdt.

Wat je vandaag leert

• Hoe je een commit message schrijft die iets zegt
• Drie simpele regels voor branching
• Wat git stash is en wanneer je het gebruikt
• De pull-voor-je-pusht regel

Deel 1: Commit messages die iets zeggen

Een slechte commit message ziet er zo uit:

git commit -m "fix"
git commit -m "update"
git commit -m "dingen veranderd"

Over drie maanden kijk je terug. Wat was “fix”? Welke “dingen”? Je weet het niet meer. Je moet door de code spitten om te achterhalen wat er gebeurd is. Dat is tijdverspilling.

De goede commit message: 3 delen

Een professionele commit message heeft drie onderdelen:

1. Een korte samenvatting (max 72 karakters)

Schrijf in het Engels. Begin met een werkwoord in de tegenwoordige tijd. Dit heet “imperative mood”: alsof je een bevel geeft aan de codebase. Denk: “Add”, “Fix”, “Remove”, “Update”, “Refactor”.

Add highscore tracking
Fix star spawning off-screen
Remove unused collision code

2. Een lege regel

3. Een langere uitleg (optioneel, als het nodig is)

Add highscore tracking

Slaat de hoogste score op in highscore.txt. De score wordt
bijgewerkt na elke game-over. Het bestand wordt aangemaakt als
het nog niet bestaat.

Dit vervangt de oude methode waarbij de score alleen in het
geheugen stond en verloren ging bij afsluiten.

De uitgebreide uitleg vertelt waarom je iets veranderd hebt, niet alleen wát. De code zelf laat het “wat” al zien. Het “waarom” is wat je over drie maanden nodig hebt.

Commit message regels op een rij

Waarom Engels? Omdat bijna alle open source-projecten Engels gebruiken. Code is internationaal. Ook je Python-code schrijf je in het Engels (def calculate_score). Je commit messages volgen diezelfde taal.

Waarom tegenwoordige tijd? Een commit beschrijft wat deze wijziging dóet, niet wat jij gedaan hébt. “Add feature” (deze commit voegt een feature toe), niet “Added feature” (ik heb ooit een feature toegevoegd). Git zelf gebruikt ook tegenwoordige tijd: Merge branch 'feature', niet Merged.

Multi-line commits in de terminal

Je kunt een commit message over meerdere regels schrijven door de aanhalingstekens niet te sluiten:

git commit -m "Add highscore tracking

Slaat de hoogste score op in highscore.txt. Het bestand wordt
automatisch aangemaakt bij de eerste game-over."

Let op: je typt het sluitende aanhalingsteken pas op de laatste regel. Alles ertussen is onderdeel van je message.

Wanneer commit je?

Commit vaak. Commit klein.

Niet: drie uur werken, één enorme commit met 47 gewijzigde bestanden. Wel: elke 15 tot 30 minuten een commit, telkens als één logisch stukje af is.

Een vuistregel: als je commit message “en” bevat, is je commit te groot. “Add highscore tracking en fix menu bug en update sprites” → dit moeten drie aparte commits zijn.

Kleine commits maken het makkelijker om:

• Te begrijpen wat er wanneer veranderd is
• Eén specifieke wijziging terug te draaien zonder andere dingen kapot te maken
• Merge conflicts op te lossen (kleine brokjes = minder conflicten)

Deel 2: Branching: drie simpele regels

Je weet al hóe je branches maakt (sessie 12). Nu: wannéér en waaróm.

Regel 1: master is altijd werkend

De master-branch is je etalage. Iemand die je repo cloned, moet je code kunnen runnen zonder foutmeldingen. master bevat nooit half-af werk.

Niet oké op master: code met # TODO: dit moet nog af, uitgecommentarieerde functies, experimenten die je “later nog fixet.”

Wel oké op master: werkende code. Punt.

Regel 2: Eén feature, één branch

Een branch doet precies één ding. Niet meer.

• Goed: feature/player-health-bar
• Slecht: feature/health-bar-and-menu-and-sound-effects

Als je tijdens het werken aan een feature denkt: “Oh, ik kan ook even die menu-bug fixen”: stop. Maak een nieuwe branch voor de bugfix. Merge die eerst. Ga dan verder met je feature.

Regel 3: Branches hebben een korte levensduur

Een branch die langer dan een paar dagen bestaat, wordt een probleem. master verandert intussen, en jouw branch raakt achterop. Hoe langer je wacht met mergen, hoe groter de kans op merge conflicts.

Merge je branch zodra de feature klaar is. Voor kleine dingen (een bugfix van 10 minuten): misschien heb je niet eens een aparte branch nodig.

Branch-naamgeving

Geef branches namen die je over een week nog begrijpt:

feature/highscore-tracking
bugfix/star-spawn-offscreen
experiment/particle-effects

De prefix (feature/, bugfix/, experiment/) vertelt meteen wat voor soort werk er in deze branch zit. Dit is een conventie, geen technische vereiste, maar het helpt.

Deel 3: Handige workflow-commando’s

git stash: werk opzij zetten

Stel: je bent bezig op een feature-branch. Je code is half af. Je wil even switchen naar master voor een snelle bugfix, maar je wil je half-affe werk niet committen. Daar is git stash voor:

git stash

Git bewaart al je wijzigingen tijdelijk en zet je working directory terug naar de laatste commit. Je kunt nu switchen, de bugfix doen, committen, en terugkomen:

git switch master
# ... bugfix doen, committen ...
git switch feature-branch
git stash pop

git stash pop haalt je opgeslagen wijzigingen terug. Alles staat weer zoals je het achterliet: half af, maar veilig bewaard.

git pull --rebase: een schonere geschiedenis

Normaal doet git pull een merge. Dat maakt een extra merge-commit aan. Soms wil je dat niet; je wil een rechte lijn van commits zonder vertakkingen.

git pull --rebase

Dit haalt de nieuwste commits op en zet jouw lokale commits erbovenop, alsof je ze ná de remote-commits gemaakt hebt. Het resultaat is een lineaire geschiedenis: geen merge-commits die alleen maar “Merge branch ‘master’” zeggen.

Let op: gebruik --rebase alleen op branches die jij alleen gebruikt. Bij gedeelde branches is gewoon git pull (merge) veiliger.

De pull-voor-je-pusht regel

Voordat je git push doet:

git pull

Altijd. Ook al denk je dat niemand anders gepusht heeft. Het kost één seconde en voorkomt dat GitHub je push weigert met “Updates were rejected because the remote contains work that you do not have locally.”

Deze regel geldt vooral als je samenwerkt. Als jij de enige bent die aan een repo werkt, is het risico kleiner, maar de gewoonte is goud waard.

Deel 4: De .gitignore die je altijd moet hebben

Elk project heeft bestanden die niet in Git horen. Je .gitignore is je eerste verdedigingslinie tegen per ongeluk wachtwoorden committen.

Minimale .gitignore voor een Python-project:

# Python
__pycache__/
*.pyc
*.pyo

# Virtual environment
venv/
.venv/

# Environment variables (bevat vaak wachtwoorden/keys)
.env

# Jouw editor
.vscode/
.idea/
*.swp
*.swo

# OS-bestanden
.DS_Store
Thumbs.db

Waarom __pycache__/ negeren? Dit zijn gecompileerde Python-bestanden die je programma automatisch aanmaakt. Ze zijn verschillend per Python-versie en per computer. Ze in Git stoppen geeft alleen maar ruis.

Waarom .env negeren? .env-bestanden bevatten vaak geheime sleutels, API-keys, database-wachtwoorden. Die mogen nooit, maar dan ook nooit in Git.

Showcase

Laat aan een coach en een buddy zien:

1. Je laatste 5 commits, met goeie commit messages.
2. Je .gitignore-bestand.
3. Een branch-naam die de feature/prefix-conventie volgt.

Tot de volgende keer!

“Nu werk je professioneel met Git. Maar er is nog één concept dat élk team gebruikt: de pull request. Je code is klaar, maar voor hij in master komt, moet iemand anders hem goedkeuren. Hoe werkt dat? Volgende keer: pull requests, de review-muur waar élke wijziging doorheen moet.”

Neem mee naar huis

1. Makkelijk: Herschrijf de commit messages van je laatste 5 commits. Gebruik de regels uit deze sessie.
2. Middel: Maak een branch met de feature/-prefix, werk erin, merge hem terug, en verwijder hem. Doe hetzelfde voor een bugfix/-branch.
3. Lastig: Gebruik git stash om half werk op te slaan, switch naar master, maak een snelle fix, push, en kom terug naar je feature met git stash pop.
4. Erg lastig: Maak een situatie waar git pull faalt (clone je repo in twee mappen, maak in beide een andere commit, push de eerste, en probeer de tweede te pushen). Los het op: git pull, merge conflict fixen, en dan pas pushen.

Sessie 15: Pull Requests: De voordeur van je project

Je hebt een feature gebouwd op een branch. Goeie commit messages, netjes gewerkt. Nu wil je je code in master zetten.

Je zou git merge kunnen doen en klaar. Maar in een team werkt dat niet. Iemand anders moet je code eerst bekijken: checken op fouten, op stijl, op dingen die je gemist hebt. Dát is een pull request.

Een pull request (PR) is een verzoek: “Haal mijn wijzigingen binnen.” Je opent hem op GitHub. Je teamgenoten bekijken je code, geven feedback. Jij past dingen aan. Pas als iedereen tevreden is, gaat de code naar master.

In deze sessie maak je je eerste pull request. Je reviewt die van een buddy. En je ervaart hoe écht teamwerk met Git voelt.

Wat je vandaag leert

• Wat een pull request is en waarom teams het gebruiken
• Een PR openen op GitHub
• Je PR updaten na feedback
• Een PR van iemand anders reviewen
• Een PR mergen en de branch opruimen

Stap 0: Voorbereiding: werken in duo’s

Vandaag werk je samen met een buddy. Spreek af wie de auteur is (die de feature bouwt) en wie de reviewer is (die de PR bekijkt). Halverwege wissel je om.

De auteur heeft een GitHub-repo nodig waar de reviewer toegang toe heeft. De makkelijkste manier:

1. De auteur maakt een repo aan op GitHub (public).
2. De auteur gaat naar Settings → Collaborators → Add people.
3. De auteur nodigt de reviewer uit met diens GitHub-username.
4. De reviewer accepteert de uitnodiging (via e-mail of GitHub-notificaties).

Nu kunnen jullie allebei pushen naar dezelfde repo.

Alternatief (zonder collaborator-toegang): de reviewer forkt de repo van de auteur en opent een PR vanaf de fork naar het origineel. Maar vandaag houden we het simpel: directe collaborator-toegang.

Stap 1: Een feature-branch maken en pushen (auteur)

De auteur cloned de repo (als dat nog niet gebeurd is) en maakt een feature-branch:

git clone https://github.com/AUTEUR_USERNAME/ons-samenwerk-project.git
cd ons-samenwerk-project
git switch -c feature/groet-functie

Maak een nieuw bestand:

echo 'def groet(naam):' > groet.py
echo '    return f"Hallo {naam}!"' >> groet.py

Commit en push:

git add groet.py
git commit -m "Add groet functie

Retourneert een begroeting voor de opgegeven naam."
git push -u origin feature/groet-functie

Stap 2: Een pull request openen (auteur)

1. Ga naar je repo op GitHub.
2. GitHub toont nu een gele balk: “feature/groet-functie had recent pushes”: klik op Compare & pull request. (Als je de balk niet ziet: klik op het Pull requests-tabblad, dan New pull request, kies base: master ← compare: feature/groet-functie.)
3. Schrijf een duidelijke titel: “Add groet functie”
4. Schrijf een beschrijving. Een goede PR-beschrijving heeft drie delen:

## Wat

Een functie `groet(naam)` die een begroeting retourneert.

## Waarom

We hebben een herbruikbare begroeting nodig voor de
gebruikersinterface. Dit voorkomt dat we op meerdere plekken
dezelfde string moeten schrijven.

## Hoe testen

```python
from groet import groet
print(groet("CoderDojo"))  # "Hallo CoderDojo!"

5. Klik **Create pull request**.

Je PR staat nu open. Iedereen met toegang tot de repo kan hem zien. GitHub toont de diff: exact welke regels je hebt toegevoegd (groen) en verwijderd (rood).

## Stap 3: Een PR reviewen (reviewer)

De reviewer opent de PR op GitHub. Dit zijn de stappen van een review:

### 1. Lees de beschrijving

Begrijp je wat deze PR doet? Zo niet, vraag om verduidelijking.

### 2. Bekijk de diff

Klik op het **Files changed**-tabblad. GitHub toont elke gewijzigde regel. Kijk naar:

- **Werkt de code?** Zou je het zelf runnen als je het cloned?
- **Is de stijl consistent?** Dezelfde naamgevingsconventies als de rest van het project?
- **Zijn er fouten?** Typo's, ontbrekende imports, logische fouten?
- **Staan er geen geheimen in?** Wachtwoorden, API-keys, tokens?
- **Is het te begrijpen?** Kan iemand die deze code voor het eerst ziet, volgen wat er gebeurt?

### 3. Geef feedback

Klik op een regel om een comment toe te voegen. Wees specifiek:

**Goeie feedback:**
> In `groet.py` regel 2: wat gebeurt er als `naam` leeg is? Misschien een default-waarde toevoegen?

**Slechte feedback:**
> Dit is niet goed.

### 4. Dien je review in

Klik op **Review changes**. Je hebt drie opties:

- **Comment**: gewoon feedback, geen beslissing.
- **Approve**: de code is goed, mag gemerged worden.
- **Request changes**: er moet iets aangepast worden voor de PR gemerged kan worden.

Bij je eerste review: kies **Approve** als alles er goed uitziet, of **Request changes** als je iets wilt laten aanpassen.

## Stap 4: Feedback verwerken (auteur)

De reviewer heeft een comment achtergelaten. De auteur past de code aan:

```bash
# Zorg dat je op je feature-branch zit
git switch feature/groet-functie

Pas groet.py aan op basis van de feedback. Bijvoorbeeld:

def groet(naam="wereld"):
    return f"Hallo {naam}!"

Commit en push:

git add groet.py
git commit -m "Add default parameter to groet functie"
git push

De nieuwe commit verschijnt automatisch in de PR. De reviewer ziet de update en kan opnieuw kijken.

Stap 5: Mergen en opruimen

Als de reviewer Approved heeft, is het tijd om te mergen.

Op GitHub, in de PR, klik je op Merge pull request. Kies Create a merge commit (de standaardoptie). Klik Confirm merge.

De feature-branch is nu samengevoegd met master. Op GitHub kun je de branch verwijderen met de Delete branch-knop die verschijnt na het mergen.

Lokaal moet je ook opruimen:

git switch master
git pull                      # haal de merge op die net op GitHub gebeurd is
git branch -d feature/groet-functie   # verwijder de lokale branch

Je master is nu up-to-date. Je feature-branch is weg, lokaal én op GitHub. Klaar voor het volgende stuk werk.

De volledige PR-workflow op een rij

1. git switch -c feature/iets        ← Maak een feature-branch
2. Werk, commit, werk, commit
3. git push -u origin feature/iets   ← Push naar GitHub
4. Open een PR op GitHub             ← Vraag om review
5. Reviewer bekijkt, geeft feedback
6. Pas code aan, commit, push        ← Feedback verwerken
7. Reviewer approved
8. Merge de PR op GitHub             ← Code naar master
9. git switch master && git pull       ← Haal master lokaal bij
10. git branch -d feature/iets       ← Ruim de branch op

Een PR van iemand anders reviewen: hoe doe je dat goed?

Een review is niet: “Ziet er goed uit.” Een goeie review is specifiek, constructief en respectvol.

Vragen die je jezelf stelt tijdens een review:

• Snap ik wat deze code doet? (Zo nee: vraag om betere comments of een duidelijkere beschrijving.)
• Doet de code wat de PR-beschrijving belooft?
• Kan dit simpeler?
• Mist er iets? (Foutafhandeling, edge cases, documentatie)
• Staan er geheimen, wachtwoorden of persoonlijke data in?
• Volgt de code de stijl van de rest van het project?

Hoe geef je feedback:

Begin met wat goed is. Wees dan specifiek over wat beter kan. Eindig met een duidelijke conclusie.

Voorbeeld:

De functie werkt precies zoals beschreven. Twee suggesties:

1. In regel 2: een default-waarde voor naam zou handig zijn.
2. Overweeg een docstring toe te voegen die uitlegt wat de functie retourneert.

Verder ziet het er goed uit. Als je deze twee dingen aanpast, approve ik hem graag.

Showcase

Wissel van rol met je buddy en doe de hele workflow nog een keer: nu ben jij de reviewer.

Laat aan een coach zien:

1. Een open pull request op GitHub met een beschrijving.
2. Minstens één review-comment op een PR van je buddy.
3. Een succesvol gemergede PR: de feature-code staat nu op master.

Tot de volgende keer!

Dit was de laatste Git-sessie. Wat je nu kunt:

• Je code versiebeheren met Git (init, add, commit, log, diff)
• Experimenteren op branches zonder master kapot te maken (branch, switch, merge)
• Je code online delen via GitHub (push, pull, clone)
• Professionele commit messages schrijven
• Samenwerken via pull requests: openen én reviewen

Dit is niet “extra”. Dit is hoe developers élke dag werken. Of je nu games maakt, websites bouwt, of AI traint: Git en GitHub zijn de gereedschappen die je project beheersbaar houden. Gebruik ze.

Neem mee naar huis

1. Makkelijk: Open een pull request voor een wijziging in een van je eigen projecten.
2. Middel: Vraag een vriend of familielid om een GitHub-account te maken. Nodig ze uit als collaborator en laat ze een PR reviewen.
3. Lastig: Draag bij aan een echt open source-project. Zoek op GitHub naar issues met het label good first issue. Fork de repo, maak een fix, en open een PR.
4. Erg lastig: Bouw een klein project met twee anderen. Gebruik branches, pull requests en reviews. Werk alsof je in een professioneel team zit.

Sessie 16: Markdown: Schrijf notities die eruitzien als het web

Je kent HTML misschien van het internet: <h1>, <p>, <a>. Maar voor notities en documentatie is HTML veel te veel typwerk. Daar is Markdown voor.

Markdown is een mini-taal die je in gewone tekst schrijft. Het ziet er leesbaar uit zónder dat je het eerst moet omzetten. En met één druk op de knop wordt het nette HTML: koppen, lijsten, links, tabellen.

In deze sessie leer je de hele basis van Markdown. Aan het einde schrijf je notities die er professioneel uitzien, op GitHub, in Obsidian, of in elk ander programma dat Markdown begrijpt.

Wat je vandaag leert

• Koppen en alinea’s maken
• Tekst opmaken: vet, cursief, doorstreept
• Lijsten en opsommingen
• Links naar andere pagina’s en websites
• Afbeeldingen invoegen
• Tabellen maken
• Horizontale lijnen en codeblokken

Waarom Markdown?

Markdown is overal:

• GitHub: elke repo heeft een README.md in Markdown. Issues, pull requests, wiki’s: allemaal Markdown.
• Obsidian, Joplin, Logseq: notitie-apps die je documenten als .md-bestanden opslaan.
• Discord, Slack, Reddit: ondersteunen Markdown voor snelle opmaak in berichten.
• Hugo (deze website!): alle sessie-pagina’s die je hier ziet, zijn geschreven in Markdown.
• Jupyter Notebooks: de tekst-cellen zijn Markdown.

Het grote voordeel: je schrijft gewone tekst. Geen ingewikkelde tags. En het resultaat is altijd leesbaar, ook als platte tekst.

Stap 0: Een Markdown-bestand maken

Markdown-bestanden eindigen op .md. Maak er één:

mkdir mijn-notities
cd mijn-notities
echo "# Mijn Eerste Notitie" > test.md

Je kunt .md-bestanden openen in elke teksteditor: Kladblok, VS Code, Thonny, Obsidian. VS Code heeft een ingebouwde preview: klik rechtsboven op het icoontje met het vergrootglas en het boek.

Stap 1: Koppen en alinea’s

Koppen maak je met #. Hoe meer #, hoe kleiner de kop:

# Dit is een titel (h1)

## Dit is een subtitel (h2)

### Dit is een kleinere kop (h3)

#### Nog kleiner (h4)

Een alinea maak je door gewoon tekst te typen. Een lege regel ertussen start een nieuwe alinea:

Dit is de eerste alinea. Die loopt gewoon door.

Dit is de tweede alinea. Omdat er een lege regel tussen zit.

Tip: één # gebruik je maar één keer per document: voor de titel. De rest begint bij ##.

Stap 2: Tekst opmaken

**Dit is vetgedrukt**

*Dit is cursief*

~~Dit is doorstreept~~

Je kunt ook **vet en *cursief* combineren** in dezelfde zin.

Het resultaat:

• **vet** wordt vet
• *cursief* wordt cursief
• ~~doorstreept~~ wordt doorstreept

Let op: geen spaties tussen de sterretjes en de tekst. ** vet ** werkt niet. **vet** wel.

Sommige editors accepteren ook underscores: __vet__ en _cursief_. Maar sterretjes zijn de standaard: gebruik die.

Stap 3: Horizontale lijnen

Een horizontale lijn maak je met drie (of meer) streepjes:

---

Of met sterretjes:

***

Het resultaat is een lijn over de hele breedte. Gebruik het spaarzaam: één of twee per document is genoeg. Te veel lijnen maken je notities onoverzichtelijk.

Stap 4: Lijsten

Ongenummerde lijst

Gebruik -, * of +:

- Python
- Git
- Markdown
- GitHub

Je kunt lijsten nesten door in te springen (2 of 4 spaties):

- Programmeertalen
  - Python
  - JavaScript
- Versiebeheer
  - Git
  - GitHub

Genummerde lijst

1. Open Thonny
2. Schrijf je code
3. Klik op Run

Het maakt niet uit welke nummers je typt: Markdown nummert automatisch door. Dit:

1. Stap één
1. Stap twee
1. Stap drie

…geeft exact hetzelfde resultaat als 1, 2, 3. Handig als je later een stap wilt toevoegen zonder alles te hernummeren.

Checklist (GitHub-stijl)

- [x] Git installeren
- [x] Eerste commit maken
- [ ] Branches leren
- [ ] Pull request openen

[x] is afgevinkt, [ ] is open. Werkt in GitHub issues, pull requests, en veel notitie-apps.

Stap 5: Links

Externe links (naar websites)

[klik hier voor de CoderDojo-site](https://python.coderdojohasselt.be)

Het woord tussen [ ] is de klikbare tekst. De URL tussen ( ) is de bestemming.

Interne links (naar andere pagina’s in je project)

[Bekijk sessie 11](11-git-intro/)

Dit linkt naar het bestand 11-git-intro/_index.md in dezelfde map.

Snel-link (toon de URL direct)

<https://github.com>

Dit toont de URL als klikbare link, zonder aparte tekst.

Stap 6: Afbeeldingen

Een afbeelding is bijna hetzelfde als een link, maar met een ! ervoor:

![Een ster in Pygame Zero](/sessions/01-catch-the-stars/coordinaten.svg)

De tekst tussen [ ] is de alt-tekst: die verschijnt als de afbeelding niet laadt, of wordt voorgelezen door screenreaders.

Afbeeldingen en Git: Kleine afbeeldingen (SVG, kleine PNG’s) kun je in Git zetten. Grote afbeeldingen (>1 MB) en video’s beter niet, want die maken je repo traag.

Stap 7: Tabellen

| Commando | Wat het doet |
|----------|-------------|
| `git init` | Nieuwe repository maken |
| `git add` | Bestanden klaarzetten voor commit |
| `git commit` | Wijzigingen vastleggen |
| `git push` | Commits naar GitHub sturen |

De | tekens vormen de kolommen. De --- regel scheidt de kop van de data. De : in de scheidingsregel bepaalt uitlijning:

| Links uitgelijnd | Gecentreerd | Rechts uitgelijnd |
|:-----------------|:-----------:|------------------:|
| links            | midden      | rechts            |

Stap 8: Code en codeblokken

Inline code

Gebruik backticks voor korte stukjes code in een zin:

Gebruik `git status` om te zien wat er gewijzigd is.

Codeblokken

Voor meerdere regels code gebruik je drie backticks:

```python
def groet(naam):
    return f"Hallo {naam}!"
```

De taal (python) achter de eerste backticks geeft syntax highlighting. Dit werkt voor tientallen talen: bash, html, css, javascript, json, yaml, markdown.

Codeblok zonder taal

```
Dit is gewoon tekst
zonder syntax highlighting
```

Stap 9: Blockquotes

Gebruik > voor citaten of belangrijke opmerkingen:

> Git is geen back-up. Git is een tijdmachine.
> Iemand op het internet

Meerdere > regels achter elkaar vormen één blok. Een lege > regel start een nieuwe alinea binnen het citaat.

Stap 10: Alles samen: een echte README

Een goed README.md combineert alles wat je nu kent. Hier is een voorbeeld:

# Mijn Project

Een korte beschrijving van wat dit project doet.

## Installatie

```bash
git clone https://github.com/jouw-naam/mijn-project.git
cd mijn-project
```

## Gebruik

1. Open `main.py` in Thonny.
2. Klik op **Run**.
3. Kies een level en start.

## Wat je leert

- [x] Pygame Zero basis
- [x] Collision detection
- [ ] Highscore systeem
- [ ] Geluidseffecten

## Links

- [CoderDojo Hasselt](https://coderdojohasselt.be)
- [Broncode op GitHub](https://github.com/jouw-naam/mijn-project)

Cheatsheet

Showcase

Laat aan een coach en een buddy zien:

1. Een Markdown-document met minstens één kop, een lijst, een link en vetgedrukte tekst.
2. Een tabel met minstens twee kolommen en drie rijen.
3. Een checklist met afgevinkte en open items.

Tot de volgende keer!

Markdown is simpel, maar het is overal. Je README’s op GitHub, je notities in Obsidian, je documentatie: alles wordt leesbaarder met Markdown. Gebruik het. Overdrijf niet met opmaak. Goeie notities zijn helder, niet druk.

Neem mee naar huis

1. Makkelijk: Schrijf een README.md voor je favoriete Python-project. Gebruik koppen, een lijst en een codeblok.
2. Middel: Maak een notitie in Obsidian (of een andere Markdown-editor) over wat je deze maand geleerd hebt. Gebruik alle opmaak uit de cheatsheet minstens één keer.
3. Lastig: Bouw een “cheatsheet”-pagina in Markdown voor een onderwerp naar keuze (Git-commando’s, Python syntax, wiskunde-formules). Gebruik tabellen en geneste lijsten.
4. Erg lastig: Maak een Markdown-document met een geneste lijst die minstens drie niveaus diep gaat, een tabel met uitlijning, en een codeblok met syntax highlighting.