# Portfolio en opdrachten

Hoe je bij de webvakken werkt met je eigen repository op GitHub, en hoe je daar feedback op krijgt.

Multimedia & Creatieve Technologie · 0.0 General · Handleiding · versie 1.0.1 · 2026-09-30

Tags: general, git, github

Slides: <https://slides.mctantwerp.be/nl/general/04-portfolio>

Speaker notes: <https://slides.mctantwerp.be/nl/general/04-portfolio.notes.md>

<!-- slide 2 -->

## Agenda

1. Hoe wij werken: Twee soorten repositories
2. Van uitnodiging tot push: Toegang, clonen, de vaste flow
3. Opdrachten: De feedback-PR
4. Portfolio: Structuur, lesbestanden, screenshots
5. Reviews: Rondes, evaluatie, de finale tag
6. Als er iets misloopt: De vijf klassiekers

<!-- slide 3 -->

## Wat je hiervoor al nodig hebt

*Drie decks uit deze General-cursus. Staan ze nog niet in je vingers, werk ze dan eerst door.*

- **[Markdown](/nl/general/01-markdown)**: Je portfolio bestaat volledig uit .md bestanden. Titels, lijsten, links, tabellen en code.
- **[Bestandsbeheer](/nl/general/02-bestandsbeheer)**: Mappen, paden en namen zonder spaties. Een repo is ook gewoon een map.
- **[De terminal](/nl/general/03-terminal)**: Git heeft geen knoppen. pwd, cd en ls heb je elke les nodig.

> [!NOTE]
> Git zelf komt uitgebreid aan bod in **Git basics** bij Programming Principles. Hier gaat het over hoe wij git bij de webvakken gebruiken.

<!-- slide 4 -->

## 1. Hoe wij werken

*Je werk en de feedback erop staan op dezelfde plek: in je eigen repository.*

<!-- slide 5 -->

**Alles staat in git.**

Geen zip op Canvas, geen mail met een bestand erbij, geen map op Drive die niemand terugvindt. Je pusht naar GitHub en je bent klaar.

<!-- slide 6 -->

### Waarom zo

- Je geschiedenis toont je proces, niet alleen je eindresultaat
- Feedback staat bij de regel code waar het over gaat, niet in een los document
- Wij zien altijd de laatste versie, jij hoeft niets op te sturen
- Je portfolio blijft van jou, ook na je opleiding
- Zo werkt het op elke werkvloer waar code gemaakt wordt

> [!TIP]
> **Bijkomend voordeel**
>
> Je GitHub-profiel is je cv. Wie na drie jaar een stage zoekt, heeft hier al een portfolio staan met echte commits erin.

<!-- slide 7 -->

### Twee soorten repositories

*Je krijgt er eentje per opdracht, en eentje per vak voor je portfolio.*

#### Opdracht-repo

- Eén per opdracht, met startcode en een README
- Heet zoiets als `web-development-2526-01-html-samserrien`
- Feedback komt in één pull request met de naam Feedback
- Na de deadline blijft hij staan, je kan hem altijd herlezen

#### Portfolio-repo

- Eén per vak, voor het hele semester
- Heet zoiets als `2526-web-development-portfolio-samserrien`
- Feedback komt in review rondes, meerdere keren per semester
- Wordt op het einde bevroren met een tag: dat is wat geëvalueerd wordt

<!-- slide 8 -->

### Wie ziet wat

*Elke repo is privé. Jij en de lectoren, en verder niemand.*

| Wie | Wat |
| --- | --- |
| Jij | Schrijfrechten op je eigen repo, en op geen enkele andere |
| De lectoren van het vak | Lezen, commentaar geven, review rondes openen |
| Je klasgenoten | Niets. Ze zien je repo niet eens staan |
| De rest van de wereld | Niets, de repo is privé |

> [!WARNING]
> De naam van je repo bevat je GitHub-username. Kies dus `voornaamachternaam` en niet `xxdarkslayer2006xx`. Je studentennummer staat er nooit in.

<!-- slide 9 -->

### De woorden die we gebruiken

*Vijf termen. Komen ze niet bekend voor, lees dan eerst Git basics.*

**Repository**: Je project met zijn volledige geschiedenis. In de praktijk: een map met een .git map erin.

**Commit**: Een vastgelegde stap in die geschiedenis, met een boodschap erbij.

**Push**: Je commits naar GitHub sturen. Wat je niet pusht, ziet niemand.

**Branch**: Een lijn in de geschiedenis. Jij werkt altijd op main.

**Pull request**: Een plek waar twee branches vergeleken worden, met commentaar per regel code.

<!-- slide 10 -->

### Je hebt gecommit maar niet gepusht. Wat ziet je lector?

- A. Niets, je commits staan enkel op je laptop
- B. Alles, commit en push zijn hetzelfde
- C. Enkel de commit-boodschap
- D. De vorige versie van je bestanden

**Antwoord:** A. Niets, je commits staan enkel op je laptop

Een commit is lokaal. Pas een push stuurt hem naar GitHub. Daarom eindigt elke werksessie met git push, ook als je nog niet klaar bent.

<!-- slide 11 -->

## 2. Van uitnodiging tot push

*De vijf minuten setup, en daarna elke les dezelfde vier commando's.*

<!-- slide 12 -->

### De uitnodiging accepteren

*Je repo is privé, dus je krijgt er een uitnodiging voor. Zonder die klik bestaat je repo niet voor jou.*

1. **Mail**: GitHub stuurt een invitation naar het adres van je account
2. **Of in GitHub zelf**: [github.com/notifications](https://github.com/notifications), of de banner bovenaan de organisatie
3. **Accept invitation**: Daarna staat de repo in je eigen lijst

> [!WARNING]
> Geen mail gezien? Kijk in spam, en controleer of je op GitHub ingelogd bent met hetzelfde account als het account dat je aan ons doorgaf. Twee accounts hebben is de nummer één oorzaak van "ik zie mijn repo niet".

<!-- slide 13 -->

### Clonen

*Eén keer per repo. Daarna staat hij gewoon op je schijf.*

```console
% cd ~/Projects
% git clone https://github.com/mctantwerp/web-development-2526-01-html-samserrien.git
% cd web-development-2526-01-html-samserrien
% code .
```

> [!TIP]
> De url staat achter de groene knop **Code** op GitHub. Clone in je projectenmap, niet in je Downloads en niet in een map die met Drive synct.

<!-- slide 14 -->

### De vaste flow

*Deze vier commando's herhaal je de rest van het semester.*

```console
% git pull
% git add .
% git commit -m "flexbox oefening afgewerkt"
% git push
```

**pull**: Haal op wat er op GitHub staat.

**add**: Zet klaar wat mee moet in de commit.

**commit**: Leg de stap vast, met een boodschap.

**push**: Stuur alles naar GitHub. Nu pas bestaat het voor ons.

<!-- slide 15 -->

### Waar je niet aan raakt

*Drie branches en een pull request die wij beheren. Laat ze staan en er kan weinig misgaan.*

#### Laat staan

- De branches `feedback` en `reviewed`: die zijn van ons
- De pull request sluiten of mergen: dat doet je lector
- `git push --force` en geschiedenis herschrijven
- De repo hernoemen, verwijderen of public zetten

#### Doe maar

- Commits pushen naar `main`, zoveel je wil
- Mappen en bestanden bijmaken die je nodig hebt
- Antwoorden op commentaar in de pull request
- Een eigen branch maken als je iets wil uitproberen

<!-- slide 16 -->

### Wat niet in je repo hoort

*Git is gemaakt voor tekst. Alles wat groot of geheim is, houd je eruit.*

```bash
# .gitignore
node_modules/
.env
.DS_Store
*.mp4
dist/
```

> [!WARNING]
> **Nooit een .env**
>
> Daar staan wachtwoorden en API-sleutels in. Eens gepusht staan ze in de geschiedenis, ook als je ze daarna verwijdert.

> [!TIP]
> **Video en grote beelden**
>
> Zet een video op YouTube of Vimeo en link ernaar. Comprimeer screenshots voor je ze commit.

<!-- slide 17 -->

## 3. Opdrachten

*Startcode, jouw werk erbovenop, en één pull request vol commentaar.*

<!-- slide 18 -->

### Wat er in je opdracht-repo staat

*Elke opdracht vertrekt van hetzelfde sjabloon, met de opdracht zelf in de README.*

- De README lees je eerst, daar staat wat gevraagd wordt
- De startcode mag je volledig verbouwen
- Je werkt op main en pusht zo vaak je wil
- Wij lezen mee in een pull request, niet in je bestanden apart

<!-- slide 19 -->

### Twee branches

*main is jouw werk. feedback is de startcode zoals je ze kreeg, en blijft bevroren staan.*

`main` / `feedback`: start, jouw werk, commit, Feedback, je fixt iets, commit

De pull request vergelijkt main met feedback. Alles wat jij erbij deed, staat erin. En omdat hij naar de branch kijkt en niet naar een commit, verschijnt elke nieuwe push er vanzelf bij.

<!-- slide 20 -->

### De Feedback-PR

*Eén pull request per opdracht-repo, die het hele semester open blijft staan.*

- **Waar**: Bovenaan je repo, tabblad Pull requests. Hij heet Feedback.
- **Wat je ziet**: Onder Files changed staat je code, met onze commentaar bij de regel waar het over gaat.
- **Blijft open**: Wij sluiten of mergen hem niet. Zo blijft alle feedback op één plek staan.
- **Volgt je pushes**: Push je iets nieuws, dan staat het meteen in dezelfde pull request.

<!-- slide 21 -->

### Zo ziet dat eruit

*Antwoord in het venster hieronder en push een commit, dan zie je wat er met de pull request gebeurt.*

**#1 Feedback** (`main` → `feedback`)

*index.html*

```diff
    <div class="top">
+     <div class="logo">MCT</div>
+     <div class="links">
+       <a href="#">Home</a>
      </div>
    </div>
```

> **Sam Serrien** (13): Drie divs na elkaar terwijl hier header, nav en een titel hoort. Bekijk de semantische elementen nog eens en pas het aan, dan is de rest van deze pagina meteen ook toegankelijker.

<!-- slide 22 -->

### Reageren op feedback

*Commentaar krijgen is het punt van de oefening. Er iets mee doen ook.*

1. **Lezen**: Klik door naar de regel code, dan zie je de context
2. **Aanpassen**: Fix het in je editor, commit en push
3. **Antwoorden**: Zeg in de thread wat je aangepast hebt, of stel je vraag
4. **Laten staan**: De thread sluiten doen wij, zo houden we het overzicht

> **Niet akkoord of niet duidelijk?**
>
> Schrijf dat gerust in de thread. Een vraag als "ik snap niet waarom een div hier fout is" levert je een beter antwoord op dan stil blijven en het laten staan.

<!-- slide 23 -->

### Deadlines

*Wat op de deadline gepusht is, is wat wij verbeteren.*

- Niet gepusht is niet ingediend, ook al staat het op je laptop
- Push tijdens het werken, niet één keer op het einde
- De geschiedenis toont wanneer je werkte, dat is geen probleem maar wel zichtbaar
- Te laat? Push toch, en zeg het erbij in de pull request

> [!TIP]
> **Vijf seconden werk**
>
> Sluit elke werksessie af met `git push`. Ook halfweg een oefening, ook als het nog niet werkt. Een commit met kapotte code is beter dan geen commit.

<!-- slide 24 -->

### Wie sluit of merget de Feedback pull request?

- A. Niemand, hij blijft open staan
- B. Jij, als je klaar bent met de opdracht
- C. GitHub, automatisch na de deadline
- D. Je klasgenoot bij een peer review

**Antwoord:** A. Niemand, hij blijft open staan

Hij blijft open zodat alle feedback op één plek staat en nieuwe pushes er vanzelf bij komen. Sluit je hem per ongeluk, heropen hem dan met Reopen, of laat het weten.

<!-- slide 25 -->

## 4. Portfolio

*Eén repository per vak waarin je toont wat je leerde, les na les.*

<!-- slide 26 -->

### Wat het portfolio is

#### Wel

- Bewijs van wat je leerde, in je eigen woorden
- Een bestand per les, bijgewerkt terwijl het nog vers is
- Code, screenshots van resultaten en je reflectie erop
- De basis voor je evaluatie, samen met je opdrachten

#### Niet

- Een samenvatting van de slides overtypen
- Een dump van alle code zonder uitleg
- Een verslag dat je de week voor de evaluatie in elkaar steekt
- Foto's van jezelf of van de klas

<!-- slide 27 -->

### De structuur

*Deze mappen staan er al in als je je portfolio krijgt. Hou je eraan, dan vindt iedereen alles terug.*

- `00-introductie` wie je bent als developer en wat je uit het vak wil halen
- `01-lessen` één bestand per les, gemaakt met les-template.md
- `02-opdrachten` de uitgewerkte opdrachten, met links naar je code
- `03-eindreflectie` je terugblik op de hele periode
- `assets` alle afbeeldingen waar je vanuit je markdown naar verwijst

<!-- slide 28 -->

### Het lesbestand

*Kopieer les-template.md, hernoem het naar de les en vul de zeven secties in.*

| Sectie | Wat erin hoort |
| --- | --- |
| Samenvatting | In enkele zinnen: wat behandelde deze les en waarom is dat belangrijk |
| Bronnen | Documentatie, artikels, video's en cursusmateriaal, met links |
| Oefeningen | Wat je maakte, met een verwijzing naar de code of het resultaat |
| Wat ik heb geleerd | Concrete dingen die je nu kan toepassen |
| Zelfreflectie | Wat vlot ging, wat moeilijk was, wat je anders aanpakt |
| Zelfevaluatie | Een tabel met je leerdoelen, een score van 1 tot 5 en toelichting |
| Inhaalbeweging | Wat je nog moet bijwerken, met een actie en een datum |

<!-- slide 29 -->

### Screenshots

*Ze horen in assets, en ze tonen een resultaat.*

> [!TIP]
> **Wel**
>
> Visuele resultaten, interfaces, diagrammen en foutmeldingen. De syntax staat in het **Markdown**-deck.

> [!WARNING]
> **Niet**
>
> Selfies, foto's van de klas, of een foto van je scherm met je gsm.

```md
## Oefeningen

De kaartjes met flexbox uitgelijnd:

![Drie kaarten naast elkaar](../assets/flexbox-resultaat.png)
```

<!-- slide 30 -->

### Waar hoort dit bestand

*Zes bestanden, vier mappen.*

<!-- slide 31 -->

### Een les die telt

*Dezelfde les, twee keer opgeschreven.*

#### Dit levert niets op

```md
## Samenvatting

We hebben flexbox gezien.

## Wat ik heb geleerd

Flexbox is handig om dingen
naast elkaar te zetten.
```

#### Dit wel

```md
## Samenvatting

Flexbox verdeelt de ruimte op één as.
De container krijgt display: flex, de
kinderen volgen justify-content.

## Wat ik heb geleerd

Verticaal centreren lukt nu met
align-items: center. Mijn kaartjes
stonden eerst onder elkaar omdat ik
display: flex op het kind zette.
```

<!-- slide 32 -->

### Je hebt een screenshot van een foutmelding. Waar zet je hem?

- A. In assets, en je verwijst ernaar vanuit je lesbestand
- B. In 01-lessen, naast je markdown
- C. In een map screenshots die je zelf aanmaakt
- D. Nergens, foutmeldingen horen niet in een portfolio

**Antwoord:** A. In assets, en je verwijst ernaar vanuit je lesbestand

Alle afbeeldingen staan in assets. Een foutmelding met je uitleg erbij is net een sterk portfolio-item: het toont wat je onderzocht hebt.

<!-- slide 33 -->

## 5. Reviews

*Meerdere keren per semester feedback, en op het einde een bevroren versie.*

<!-- slide 34 -->

### Hoe een review ronde werkt

*Wij openen een pull request van main naar reviewed, jij blijft gewoon pushen.*

`main` / `reviewed`: les 1, review 1, afgesloten, les 2 tot 6, review 2, afgesloten, final

Elke ronde toont wat er sinds de vorige ronde bijkwam. Wordt een ronde afgesloten, dan schuift reviewed mee en begint de volgende ronde met een schone lei.

<!-- slide 35 -->

### Wat jij doet tijdens een ronde

*Niets bijzonders, en dat is de bedoeling.*

1. **Blijf pushen**: Je commits verschijnen vanzelf in de open ronde
2. **Lees de commentaar**: Per bestand, per regel, in de pull request
3. **Werk bij**: Pas aan en push, in dezelfde ronde
4. **Antwoord**: Kort in de thread: wat je aanpaste of waar je vastzit

> [!NOTE]
> Staat er geen ronde open, dan is er even niets te doen. Je blijft je portfolio gewoon bijwerken, en de volgende ronde pikt alles mee wat je intussen pushte.

<!-- slide 36 -->

### De finale ronde

*Op het einde van de periode zetten we een tag op de laatste commit. Die tag verandert nooit meer.*

```console
% git log --oneline -3
a1b2c3d les 12 en eindreflectie
9f8e7d6 les 11 afgewerkt
4c5b6a7 screenshots toegevoegd
% git tag
p1-final
```

> [!WARNING]
> **Wat er dan staat, telt**
>
> De tag wijst naar één exacte commit. Wat je daarna nog pusht, staat er wel, maar het is niet wat geëvalueerd werd.

> [!TIP]
> **Twee periodes**
>
> Sommige vakken evalueren in periode 1 en periode 4. Dan staat je werk in de mappen `p1/` en `p4/`, elk met hun eigen rondes en hun eigen tag.

<!-- slide 37 -->

### Zo haal je er iets uit

- Werk je lesbestand bij op de dag van de les, niet in het weekend voor de evaluatie
- Schrijf ook op wat niet lukte en hoe je het oploste, daar zit je leerproces
- Stel concrete vragen in de pull request, dan krijg je concrete antwoorden
- Gebruik de zelfevaluatietabel eerlijk, een 3 met uitleg is meer waard dan overal een 5
- Werk je inhaalbeweging af voor de volgende ronde, dan zien we vooruitgang

> **Waarom meerdere rondes?**
>
> Feedback die je pas op het examen krijgt, is een cijfer. Feedback halfweg is iets waar je nog iets mee kan.

<!-- slide 38 -->

### Wanneer verschijnt je nieuwe commit in de open review ronde?

- A. Meteen na je push
- B. Pas als de lector de ronde opnieuw opent
- C. Na de deadline van de periode
- D. Enkel als je het zelf meldt

**Antwoord:** A. Meteen na je push

De pull request kijkt naar de branch main, niet naar een vaste commit. Alles wat je pusht, verschijnt er dus vanzelf in. Wel handig om in de thread te zeggen dat je iets aanpaste.

<!-- slide 39 -->

## 6. Als er iets misloopt

*Vijf klassiekers en wat je eraan doet.*

<!-- slide 40 -->

### De vijf klassiekers

| Wat je ziet | Wat er aan de hand is | Wat je doet |
| --- | --- | --- |
| Ik zie mijn repo niet staan | De uitnodiging staat nog open, of je bent ingelogd met een ander account | Check je mail en [github.com/notifications](https://github.com/notifications) |
| `Permission denied` | Git pusht met een ander account dan het jouwe | Log opnieuw in, of gebruik de GitHub-extensie in VS Code |
| `Updates were rejected` | Er staat iets op GitHub dat jij nog niet hebt | `git pull` en daarna opnieuw pushen |
| Merge conflict | Jij en je andere machine bewerkten dezelfde regels | Kies in VS Code welke versie blijft, commit en push |
| De pull request staat op closed | Hij is per ongeluk gesloten | Klik Reopen, of laat het ons weten |

<!-- slide 41 -->

### Zet je notificaties aan

*Feedback die je niet leest, is geen feedback.*

- GitHub mailt je bij commentaar op je pull request
- Instellen staat op [github.com/settings/notifications](https://github.com/settings/notifications)
- Zet Participating aan, dan krijg je enkel wat over jou gaat
- De mobiele app van GitHub werkt ook, en leest prettiger dan mail

> [!TIP]
> **Eén keer per week volstaat**
>
> Kijk je liever niet in je mail, neem dan een vast moment: elke maandag je pull requests openen en zien wat erbij kwam.

<!-- slide 42 -->

### Checklist

*Twee lijstjes die je de rest van het semester meegaan.*

- **Na elke les**: Lesbestand invullen terwijl het vers is, screenshots in assets, commit en push. Tien minuten werk.
- **Na elke oefening**: Commit met een boodschap die zegt wat je deed, en push. Ook als het nog niet af is.
- **Elke week**: Je open pull requests bekijken, antwoorden op commentaar, je inhaalbeweging bijwerken.
- **Voor een deadline**: `git status` moet leeg zijn, en je werk moet op GitHub staan. Controleer het in je browser.

<!-- slide 43 -->

### Extra

- **[Markdown](/nl/general/01-markdown)**: De syntax van je portfolio: titels, lijsten, links, tabellen en code.
- **[De terminal](/nl/general/03-terminal)**: Navigeren, clonen en de commando's die git nodig heeft.
- **[Git basics](/nl/programming-principles/02-git-basics)**: Wat een commit is, hoe git denkt, en de flow in detail.
- **[docs.github.com](https://docs.github.com/en/pull-requests)**: De documentatie van GitHub over pull requests en reviews.

## Begrippen

- **Opdracht-repo**: Eén repository per opdracht, met startcode en een README waarin de opdracht staat. De feedback komt in één pull request met de naam Feedback. (slide 7)
- **Portfolio-repo**: Eén repository per vak voor het hele semester, met een lesbestand per les. Feedback komt in review rondes, en op het einde bevriest een tag wat geëvalueerd wordt. (slide 7)
- **Uitnodiging**: Je repo is privé, dus GitHub stuurt je een invitation per mail en op github.com/notifications. Pas na Accept invitation zie je de repo, op voorwaarde dat je met het account ingelogd bent dat je aan ons doorgaf. (slide 12)
- **Clonen**: Een repo één keer van GitHub naar je schijf halen met git clone en de url achter de groene knop Code. Doe het in je projectenmap, niet in Downloads of in een map die met Drive synct. (slide 13)
- **.gitignore**: Een bestand in je repo met wat git moet laten liggen, zoals node_modules/, .env en video's. Een .env die toch gepusht is, blijft in de geschiedenis staan. (slide 16)
- **Feedback-PR**: De pull request in elke opdracht-repo die main vergelijkt met de branch feedback, de startcode zoals je ze kreeg. Hij blijft het hele semester open en elke nieuwe push verschijnt er vanzelf in. (slide 20)
- **Review ronde**: Een pull request van main naar reviewed in je portfolio-repo, met commentaar op wat er sinds de vorige ronde bijkwam. Jij blijft gewoon pushen, je commits verschijnen er vanzelf in. (slide 34)
- **Tag**: Een vaste naam op één exacte commit, zoals p1-final. De tag op het einde van de periode verandert nooit meer: die versie wordt geëvalueerd. (slide 36)
- **Lesbestand**: Het bestand per les in 01-lessen, een kopie van les-template.md met zeven secties. Je vult het in op de dag van de les, niet in het weekend voor de evaluatie. (slide 28)
- **Zelfevaluatie**: De sectie in je lesbestand met een tabel van je leerdoelen, een score van 1 tot 5 en een toelichting. Een 3 met uitleg is meer waard dan overal een 5. (slide 28)
- **Inhaalbeweging**: De sectie in je lesbestand met wat je nog moet bijwerken, telkens met een actie en een datum. Werk ze af voor de volgende review ronde. (slide 28)
- **assets**: De map in je portfolio waar elke afbeelding staat, ook een screenshot van een foutmelding. Vanuit je markdown verwijs je ernaar: ../assets/flexbox-resultaat.png. (slide 27)
- **Merge conflict**: Twee versies veranderden dezelfde regels, bijvoorbeeld op je laptop en op je andere machine. Je kiest in VS Code welke versie blijft, en dan commit en push je. (slide 40)
- **Updates were rejected**: Git weigert je push omdat er op GitHub iets staat dat jij nog niet hebt. Doe eerst git pull en push daarna opnieuw. (slide 40)

## Links en bronnen

### In de presentatie

- [github.com/notifications](https://github.com/notifications) (slide 12, slide 40)
- [github.com/settings/notifications](https://github.com/settings/notifications) (slide 41)
- [docs.github.com](https://docs.github.com/en/pull-requests) (slide 43)