# Wat is een fork, en wat is een pull request?

- Link: https://opensourcecad.nl/technische-uitleg/wat-is-een-fork-en-wat-is-een-pull-request/
- Published: 2026-10-22T04:06:21+02:00
- Author: Marijn van den Heuvel \+ AI

_English version: [What is a fork, and what is a pull request?](https://opensourcecad.nl/en/what-is-a-fork-and-what-is-a-pull-request/)._

In berichten over open-source CAD komen twee woorden steeds terug: fork en pull 
request. Dit is wat ze betekenen.

## Een fork

De code van een open-source CAD-programma staat in een repository, met de hele geschiedenis
erbij. Een fork is jouw eigen kopie van die code, en die blijft gekoppeld aan het
originele repository. Je mag er alles in veranderen zonder dat het origineel er 
iets van merkt, en je hebt daar geen toestemming voor nodig.

Omdat die koppeling blijft bestaan, kun je twee kanten op: wat het origineel verbetert
kun je in jouw kopie ophalen, en jouw wijzigingen kun je terugsturen. Dat ophalen
gebeurt alleen als jij het vraagt, en alleen als er geen conflicten zijn met de 
broncode. Zijn die er wel, dan moet je ze eerst zelf oplossen. In open source is
forken de normale manier van werken: wie iets wil aanpassen en niet wil wachten,
begint een kopie.

## Een pull request

Een pull request, kortweg PR, is een voorstel om de broncode van een project te 
wijzigen. Je legt uit wat je veranderd hebt, de beheerders kijken ernaar, en pas
als iemand het goedkeurt wordt je wijziging samengevoegd. Dat samenvoegen heet merge.

Het is een verzoek, geen opdracht. Dat zit in de naam: je vraagt de eigenaar om 
je werk binnen te halen. Er kan ook niets mee gebeuren, en dat komt vaak voor.

## Voor en nadelen van een fork

 * Je kunt meteen beginnen, zonder toestemming te vragen en zonder in de rij te 
   staan.
 * Je hebt volledige vrijheid over wat je verandert.
 * Maar je houdt er een tweede kopie van de code mee bij, die je zelf moet onderhouden.
 * Loop je te ver uit elkaar, dan lukt het samenvoegen later niet meer.

## Voor en nadelen van een pull request

 * Je werk komt in het echte programma, waar iedereen het gebruikt.
 * Anderen kijken erover mee, en dat verbetert de kwaliteit.
 * Je hoeft geen tweede versie van de code te onderhouden.
 * Maar je voorstel moet wel bijgehouden worden tegen de wijzigingen in de code.
   Raakt het te ver achter, dan werkt je aanpassing niet meer.
 * En het kan lang duren of nooit gebeuren, want het hangt af van iemand anders.

## Waarom je het merkt

Twee CAD-programma’s die op elkaar lijken, delen vaak dezelfde oorsprong. En het
verklaart waarom een programma soms jaren hetzelfde aanvoelt: een verbetering is
geen knop die omgaat, maar een voorstel dat nagekeken en goedgekeurd moet worden.
Staat het achteraan in de rij, dan duurt het.

De uitleg over forken staat in de [documentatie van GitHub](https://docs.github.com/en/pull-requests/how-tos/work-with-forks/fork-a-repo),
net als die over [pull requests](https://docs.github.com/en/pull-requests/reference/pull-requests).