← Terug naar tutorials

Hoe beginners snel aan de slag gaan

beginnersbasisuitlegstap-voor-staphandleiding

Introductie tot het onderwerp: een beginnersgids

Deze tutorial is een complete beginnersgids om een praktisch, veelgebruikt onderwerp grondig te leren: werken met Git en GitHub. Je leert niet alleen wat Git is, maar vooral hoe je het gebruikt in echte projecten, met echte commando’s, typische workflows, en oplossingen voor veelvoorkomende problemen. Alles is geschreven voor beginners, maar met voldoende diepgang zodat je na afloop zelfstandig kunt werken.

Inhoud

  1. Wat is Git (en wat is het niet)?
  2. Git installeren en configureren
  3. Je eerste repository: init, status, add, commit
  4. De mentale modellen: working tree, staging area, history
  5. Branches: waarom, wanneer en hoe
  6. Mergen en conflicten oplossen
  7. Remote repositories (GitHub): clone, fetch, pull, push
  8. Samenwerken: pull requests, reviews en basis-afspraken
  9. Handige tools en commando’s voor dagelijks gebruik
  10. Veelgemaakte fouten en herstelacties
  11. Aanbevolen workflow voor beginners
  12. Afsluiting en volgende stappen

Wat is Git (en wat is het niet)?

Git is een gedistribueerd versiebeheersysteem (version control system). Het helpt je om:

Versiebeheer in één zin

Git bewaart een geschiedenis van snapshots van je project, zodat je kunt zien wat er veranderde, wanneer, door wie, en je kunt terugrollen of combineren.

Gedistribueerd betekent

Iedere ontwikkelaar heeft een volledige kopie van de geschiedenis op zijn eigen machine. Je bent dus niet afhankelijk van één centrale server om commits te kunnen maken of geschiedenis te raadplegen. Een remote (zoals GitHub) is vooral een gedeelde plek om samen te werken en te publiceren.

Git is niet hetzelfde als GitHub

Git installeren en configureren

Installatie controleren

Open een terminal (macOS/Linux) of PowerShell/Git Bash (Windows) en voer uit:

git --version

Je ziet iets als git version 2.xx.x. Als dat niet werkt, installeer Git via:

Basisconfiguratie: naam en e-mail

Git plaatst je naam/e-mail in commits. Stel dit één keer in:

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

Controleer:

git config --global --list

Standaard editor instellen (optioneel maar handig)

Bijvoorbeeld VS Code:

git config --global core.editor "code --wait"

Line endings (Windows tip)

Op Windows kan dit nuttig zijn:

git config --global core.autocrlf true

Op macOS/Linux meestal:

git config --global core.autocrlf input

Je eerste repository: init, status, add, commit

We maken een klein project en zetten het onder versiebeheer.

1) Maak een map en initialiseer Git

mkdir demo-git
cd demo-git
git init

Dit maakt een verborgen map .git/ aan met alle metadata.

2) Maak een bestand

echo "# Demo Git" > README.md

3) Bekijk de status

git status

Je ziet dat README.md “untracked” is: Git ziet het bestand, maar volgt het nog niet.

4) Voeg toe aan de staging area

git add README.md

Controleer opnieuw:

git status

Nu staat het bestand “staged”: klaar om in een commit te gaan.

5) Maak een commit

git commit -m "Voeg README toe"

Je project heeft nu een eerste commit in de geschiedenis.

6) Bekijk de commitgeschiedenis

git log

Handiger (compact):

git log --oneline --decorate --graph

De mentale modellen: working tree, staging area, history

Git wordt veel makkelijker als je drie zones begrijpt:

  1. Working tree: jouw huidige bestanden op schijf (wat je in je editor ziet).
  2. Staging area (index): een “wachtruimte” waarin je precies kiest wat in de volgende commit komt.
  3. Repository history: de commits die al vastgelegd zijn.

Waarom staging?

Staging is handig omdat je niet verplicht bent om alles in één keer te committen. Stel je hebt twee losse veranderingen gedaan (een bugfix en een tekstupdate). Dan kun je ze scheiden:

Dit maakt je geschiedenis leesbaar en professioneel.

Voorbeeld: meerdere wijzigingen

Maak een extra regel in README:

echo "Dit is een test." >> README.md

Check:

git diff

git diff toont het verschil tussen working tree en staging area (dus: wat je nog niet staged hebt).

Stage het bestand:

git add README.md

Nu is git diff leeg (want alles is staged). Bekijk staged diff:

git diff --staged

Commit:

git commit -m "Werk README bij"

Branches: waarom, wanneer en hoe

Een branch is een aparte ontwikkellijn. In plaats van direct op main (of master) te werken, maak je een branch voor een feature of fix. Dit voorkomt rommel op de hoofdbranch en maakt samenwerking veilig.

Branch bekijken

git branch

De ster * geeft de huidige branch aan.

Nieuwe branch maken en ernaartoe gaan

git switch -c feature/intro-tekst

(Oudere Git-versies gebruiken git checkout -b ..., maar switch is duidelijker.)

Werk doen op de branch

Voeg tekst toe:

echo "Extra introductie op feature-branch." >> README.md
git add README.md
git commit -m "Voeg extra introductie toe"

Terug naar main

git switch main

Je ziet dat die extra regel weg is in je working tree, omdat main die commit niet heeft.

Mergen en conflicten oplossen

Merge zonder conflict

Merge je feature-branch in main:

git merge feature/intro-tekst

Als alles goed gaat, worden commits gecombineerd en staat main nu op hetzelfde punt.

Conflicten: wat zijn dat?

Een merge conflict ontstaat wanneer Git niet automatisch kan bepalen hoe twee sets wijzigingen gecombineerd moeten worden. Dit gebeurt meestal wanneer:

Conflict demonstreren (bewust)

Maak twee branches die dezelfde regel aanpassen.

  1. Start op main:
git switch main
  1. Maak branch A:
git switch -c feature/a

Pas README aan (bijv. eerste regel):

printf "# Demo Git (A)\n" > README.md
git add README.md
git commit -m "Wijzig titel naar A"
  1. Terug naar main en branch B:
git switch main
git switch -c feature/b

Pas dezelfde regel anders aan:

printf "# Demo Git (B)\n" > README.md
git add README.md
git commit -m "Wijzig titel naar B"
  1. Merge A in B (of andersom) om conflict te forceren:
git merge feature/a

Je krijgt nu een conflictmelding.

Conflict oplossen

Open README.md. Je ziet markers zoals:

<<<<<<< HEAD
# Demo Git (B)
=======
# Demo Git (A)
>>>>>>> feature/a

Kies de juiste versie (of combineer), verwijder de markers, bijvoorbeeld:

# Demo Git (A + B)

Daarna:

git add README.md
git commit -m "Los merge conflict op tussen A en B"

Belangrijk: een conflict is geen “kapotte repo”, maar een signaal dat jij een keuze moet maken.

Remote repositories (GitHub): clone, fetch, pull, push

Een remote is een verwijzing naar een repository op een server (bijv. GitHub). Hiermee kun je delen, back-uppen en samenwerken.

Een repo clonen

Als er al een GitHub-repo bestaat:

git clone https://github.com/jouwnaam/jouwrepo.git
cd jouwrepo

Dit maakt een lokale kopie met remote origin.

Remote bekijken

git remote -v

Push: lokale commits naar GitHub

Als je lokaal commits hebt en de remote bestaat:

git push -u origin main

-u zet de upstream zodat je later simpel git push kunt doen.

Fetch vs pull (belangrijk verschil)

Voorbeeld:

git fetch origin
git log --oneline --decorate --graph --all

Daarna pas integreren:

git pull

Push van een feature-branch

git push -u origin feature/intro-tekst

Samenwerken: pull requests, reviews en basis-afspraken

Op GitHub werk je vaak met Pull Requests (PR’s):

  1. Je maakt een branch (bijv. feature/login)
  2. Je pusht die branch naar GitHub
  3. Je opent een PR naar main
  4. Teamgenoten reviewen
  5. Na akkoord merge je

Waarom PR’s?

Basis-afspraken die veel teams gebruiken

Handige tools en commando’s voor dagelijks gebruik

git status (meest gebruikte commando)

Toont:

git status

git log met grafiek

Superhandig om branches te begrijpen:

git log --oneline --graph --decorate --all

git diff varianten

git diff
git diff --staged
git diff <commit1> <commit2>

Bestanden tijdelijk negeren: .gitignore

Maak .gitignore:

printf "node_modules/\n.env\n.DS_Store\n" > .gitignore
git add .gitignore
git commit -m "Voeg .gitignore toe"

Belangrijk: .gitignore werkt vooral voor untracked bestanden. Als iets al gecommit is, moet je het eerst uit tracking halen (zonder te verwijderen):

git rm --cached -r node_modules

git stash (tijdelijk werk parkeren)

Handig als je halverwege iets zit en snel moet switchen:

git stash
git switch main

Later terugzetten:

git stash pop

Of meerdere stashes beheren:

git stash list
git stash apply stash@{0}

Veelgemaakte fouten en herstelacties

Herstellen is een groot deel van Git. Hieronder een aantal scenario’s met echte commando’s.

1) “Ik heb iets gecommit met een verkeerde message”

Als de commit nog niet gepusht is:

git commit --amend -m "Nieuwe correcte message"

Als je ook bestanden wilt toevoegen aan die laatste commit:

git add README.md
git commit --amend --no-edit

2) “Ik heb per ongeluk een bestand gestaged”

Unstage (bestand blijft wel gewijzigd):

git restore --staged README.md

Alles unstagen:

git restore --staged .

3) “Ik wil lokale wijzigingen weggooien”

Let op: dit kan werk vernietigen.

git restore README.md

Alles terug naar laatste commit:

git restore .

4) “Ik heb een commit gemaakt, maar ik wil hem ongedaan maken zonder geschiedenis te herschrijven”

Gebruik revert (veilig, vooral als al gepusht):

git revert <commit-hash>

Dit maakt een nieuwe commit die de wijzigingen terugdraait.

5) “Ik heb commits gemaakt op de verkeerde branch”

Vaak kun je dit oplossen door de commit(s) te verplaatsen met cherry-pick.

Stel: je zit op main maar had op feature/x moeten werken.

  1. Maak/switch naar de juiste branch:
git switch -c feature/x
  1. Cherry-pick de commit(s) (hashes via git log --oneline):
git cherry-pick <commit-hash>
  1. Verwijder de commits van main (alleen als nog niet gepusht; anders beter revert): Bijvoorbeeld main terugzetten naar remote:
git switch main
git reset --hard origin/main

6) “Mijn branch loopt achter op main”

Je kunt mergen:

git switch feature/x
git merge main

Of rebasen (nettere lineaire geschiedenis, maar wees voorzichtig als je al gedeeld hebt):

git switch feature/x
git rebase main

Als er conflicten zijn tijdens rebase:

git add .
git rebase --continue

Stoppen met rebase:

git rebase --abort

Aanbevolen workflow voor beginners

Hier is een eenvoudige, veilige workflow die in veel teams werkt:

  1. Update main lokaal
  2. Maak een feature-branch
  3. Werk in kleine commits
  4. Push je branch
  5. Open een PR
  6. Merge na review
  7. Verwijder de branch

Stap-voor-stap met commando’s

  1. Zorg dat main up-to-date is:
git switch main
git pull
  1. Maak een branch:
git switch -c feature/nieuwe-functie
  1. Werk en commit regelmatig:
# bewerk bestanden...
git add .
git commit -m "Implementeer basis van nieuwe functie"
  1. Push:
git push -u origin feature/nieuwe-functie

  1. Open PR op GitHub (via webinterface)

  2. Na merge: sync lokaal:

git switch main
git pull
  1. Verwijder lokale branch (optioneel):
git branch -d feature/nieuwe-functie

Verwijder remote branch (optioneel, vaak automatisch na merge op GitHub):

git push origin --delete feature/nieuwe-functie

Afsluiting en volgende stappen

Je hebt nu een stevige basis in Git:

Volgende stappen om verder te groeien

Als je wilt, kan ik ook een oefenopdrachtenset maken (met scenario’s zoals “conflict oplossen”, “per ongeluk commit op main”, “stash gebruiken”) inclusief verwachte uitkomsten en controlecommando’s.

Gerelateerde tutorials

Snel met Docker: bouw en draai je eerste container Hoe je snel REST API's bouwt met Python Flask Hoe je snel met Docker containers bouwt en draait