Projectopdracht: bouw een wiki met Git

Je bouwt een kleine wiki over een universum naar keuze: Harry Potter, Lord of the Rings, Marvel, een game, een sportcompetitie, een muziekgenre. Wat je kiest maakt niet uit, zolang je er zelf iets over te vertellen hebt.

De wiki is het decor. Wat beoordeeld wordt, is hoe je met Git werkt: hoe je je werk opdeelt in commits, hoe je een branch gebruikt, hoe je bestanden buiten je repository houdt, en hoe je een merge conflict oplost.

Deze opdracht telt mee voor 30% van je eindcijfer en maak je individueel.

Drie data om nu al te noteren

Wanneer	Wat
Week van 16 november 2026	De sjabloonrepository komt online. Fork ze deze week nog, en geef je GitHub-gebruikersnaam door via de uploadzone op Digitap
Maandag 7 december 2026	Er verschijnt een wijziging in de sjabloonrepository. Vanaf dan haal je die binnen in je fork en los je het conflict op
Zondag 20 december 2026, 23.59 uur	Deadline. Commits die daarna gemaakt worden, tellen niet mee

Stap 1 – Forken en klonen

Ga naar de sjabloonrepository en klik rechtsboven op Fork. Laat de naam ongewijzigd en zorg dat je fork publiek blijft.

Kloon je eigen fork naar je computer:

git clone https://github.com/JOUW-GEBRUIKERSNAAM/wiki-project.git
cd wiki-project

Voeg de sjabloonrepository toe als tweede remote, onder de naam upstream. Die heb je in stap 5 nodig:
```
git remote add upstream https://github.com/AP-IT-Essentials/wiki-project.git
git remote -v
```
Je hoort nu vier regels te zien: origin (je eigen fork) en upstream (de sjabloon), elk twee keer.
Geef je GitHub-gebruikersnaam door via de uploadzone op Digitap. Zonder die gebruikersnaam kan je werk niet gevonden en dus niet beoordeeld worden.

Fork deze week

Wie pas na 7 december forkt, krijgt de gewijzigde sjabloon binnen en kan het conflict uit stap 5 niet meer krijgen. Dat onderdeel is dan verloren.

Stap 2 – Je wiki vullen

De sjabloon bevat drie bestanden: README.md, docs/personages.md en docs/locaties.md. Vul ze met jouw universum.

Bestand	Wat erin komt
`README.md`	De titel van je wiki en een korte inleiding van vijf tot tien regels over het gekozen universum
`docs/personages.md`	De tabel met minstens vijf personages. De drie regels met `VUL AAN` vervang je door echte personages
`docs/locaties.md`	Minstens drie locaties, elk met een korte beschrijving

Werk dat in minstens vier commits, elk met één afgebakende wijziging. Alles in één commit gooien voldoet niet: de opdracht gaat er net over hoe je je werk opdeelt.

Een commit-boodschap zegt wat je deed, en waar nuttig waarom:

# Zo wel
git commit -m "Voeg vijf hoofdpersonages toe aan de personagetabel"
git commit -m "Beschrijf Zweinstein en het Verboden Bos in locaties"

# Zo niet
git commit -m "update"
git commit -m "wiki"

Stap 3 – Bestanden buiten je repository houden

Niet alles wat in je projectmap staat, hoort in je repository thuis.

Maak in je projectmap een bestand klad.md met persoonlijke notities, en een bestand export.log met wat willekeurige tekst.
Zorg dat geen van beide in je repository terechtkomt, ook niet als er later nog logbestanden bij komen. Je .gitignore bevat dus een regel voor klad.md en een patroon voor logbestanden.
Commit je .gitignore.
Controleer met git status dat de twee bestanden nergens meer opduiken.

Stap 4 – Werken met een branch en een pull request

Nieuwe inhoud maak je niet rechtstreeks op main, maar op een aparte branch.

Maak een branch met een beschrijvende naam die begint met feature/, bijvoorbeeld feature/verhaallijn.
Voeg op die branch één nieuwe pagina toe in docs/, van minstens 150 woorden, over een onderwerp naar keuze binnen je universum. Werk in minstens twee commits.
Push de branch naar je fork:
```
git push -u origin feature/verhaallijn
```
Open op GitHub een pull request van je feature branch naar de main van je eigen fork. Schrijf een titel en een korte beschrijving van wat je toevoegde.
Merge je eigen pull request op GitHub.
Haal het resultaat lokaal binnen met git pull, en verwijder de branch lokaal.

Let op de richting van je pull request

GitHub stelt standaard voor om een pull request te openen naar de sjabloonrepository. Dat is niet de bedoeling. Zet links de basisrepository op jouw fork, en pas dan op je feature branch.

Stap 5 – Het conflict oplossen (vanaf 7 december)

Op maandag 7 december wijzigt de sjabloonrepository: de personagetabel krijgt er een kolom bij. Jij hebt diezelfde tabel intussen ingevuld, dus Git kan de twee versies niet zomaar samenvoegen. Dat is de bedoeling.

Haal de wijziging op en probeer ze samen te voegen:
```
git fetch upstream
git merge upstream/main
```
Git meldt een conflict in docs/personages.md. Open het bestand: je ziet de markeringen <<<<<<<, ======= en >>>>>>>.
Los het conflict op. Een goede oplossing behoudt jouw personages én neemt de nieuwe kolom over: je vult die kolom dus in voor je eigen personages.
Verwijder alle conflictmarkeringen, sla op, en rond de merge af:
```
git add docs/personages.md
git commit
git push
```
Controleer op GitHub dat je tabel klopt en dat er nergens nog <<<<<<< in je bestanden staat.

Wat je niet doet

Het conflict "oplossen" door de sjabloonversie volledig over te nemen, of door jouw versie te forceren met git checkout --ours, levert geen punten op. De opdracht is net om beide kanten te combineren.

Stap 6 – Indienen

Er is niets op te laden. Je fork is je inzending. Zorg dat op de deadline:

je fork publiek is en op je GitHub-account staat;
je GitHub-gebruikersnaam via Digitap doorgegeven is;
alle stappen hierboven in je geschiedenis terug te vinden zijn;
er geen conflictmarkeringen meer in je bestanden staan.

Spelregels

Regel	Waarom
Commit lokaal, met Git. Bestanden aanmaken of bewerken via de GitHub-website telt niet mee als commit	De opdracht toetst of je met Git kan werken, niet met een webformulier. Webcommits zijn herkenbaar aan de committer `GitHub`
Herschrijf je geschiedenis niet. Geen `rebase`, geen `commit --amend` op gepushte commits, geen `push --force`	Je geschiedenis is je inzending. Wie ze herschrijft, wist het bewijs van zijn eigen werk
Werk individueel. Je mag over Git-commando's overleggen, niet over inhoud kopiëren	Forks zijn publiek, dus identieke wiki's vallen op
Je fork blijft publiek tot na de beoordeling	Anders kan je werk niet bekeken worden

Puntenverdeling

Onderdeel	Punten	Waarop gelet wordt
Commits en geschiedenis	25	Minstens vier commits op `main`, elk met één afgebakende wijziging en een boodschap die zegt wat er gebeurde. Lokaal gemaakt
Branch en pull request	20	Een `feature/`-branch met minstens twee commits, een pull request naar je eigen `main`, en een merge die in de geschiedenis zichtbaar is
`.gitignore`	15	Het bestand is aanwezig en gecommit; `klad.md` en logbestanden staan niet in de repository
Merge conflict	25	De wijziging van 7 december is binnengehaald, het conflict is opgelost met behoud van beide kanten, en er staan geen markeringen meer in de bestanden
Inhoud van de wiki	15	De drie sjabloonbestanden zijn ingevuld volgens de minimumeisen, plus de extra pagina uit stap 4
Totaal	100

Waar de meeste punten verloren gaan

Te laat beginnen. Wie pas de week voor de deadline start, komt het conflict van 7 december niet meer tegen zoals bedoeld, en dat is een kwart van de punten. Begin dus in de week van 16 november, ook al is het maar met je fork en je eerste commit.

Vastgelopen? Vraag het in de les

Deze opdracht maak je thuis, maar je hoeft er niet alleen mee te blijven zitten. Loop je vast op een commando, op je pull request of op het conflict, spreek me dan aan op een rustig moment tijdens een contactmoment. Even meekijken lost meestal in twee minuten op waar je thuis een uur op zou zoeken, en vragen stellen kost je geen punten.

Veelgestelde vragen

Ik heb per ongeluk klad.md gecommit voor ik mijn .gitignore maakte. .gitignore werkt enkel op bestanden die Git nog niet volgt. Haal het bestand uit de index met git rm --cached klad.md, en commit dat samen met je .gitignore.

Mijn pull request staat open naar de sjabloonrepository. Sluit hem en maak een nieuwe aan met jouw fork als basisrepository. Zie de tip bij stap 4.

Ik krijg refusing to merge unrelated histories. Dan heb je de sjabloon met Use this template aangemaakt in plaats van geforkt. Fork opnieuw en zet je werk over, of vraag hulp tijdens het contactmoment.

Ik zie geen conflict bij git merge upstream/main. Controleer of je de drie VUL AAN-regels in docs/personages.md effectief vervangen hebt, en of je remote upstream naar de juiste repository wijst met git remote -v.

Mag mijn wiki over hetzelfde universum gaan als dat van een klasgenoot? Ja. Identieke teksten zijn wel plagiaat, en op publieke forks meteen zichtbaar.

Stap 1 – Forken en klonen​

Stap 2 – Je wiki vullen​

Stap 3 – Bestanden buiten je repository houden​

Stap 4 – Werken met een branch en een pull request​

Stap 5 – Het conflict oplossen (vanaf 7 december)​

Stap 6 – Indienen​

Spelregels​

Puntenverdeling​

Veelgestelde vragen​