```html

Git voor developers: van init tot deploy

Elke developer kent het gevoel: je hebt urenlang aan een feature gewerkt, je slaat op, en dan gaat er iets mis. De productieserver draait een versie die je niet meer herkent, een collega heeft intussen wijzigingen doorgevoerd die botsen met jouw code, en je hebt geen idee welke versie nu eigenlijk "de goede" is. Dit is precies het probleem dat Git oplost — en waarom iedere serieuze developer er dagelijks mee werkt.

Git is het meest gebruikte versiebeheersysteem ter wereld. Het stelt je in staat om wijzigingen bij te houden, samen te werken zonder elkaars werk te overschrijven, en met vertrouwen te deployen naar productie. In dit artikel loop je door de volledige Git-workflow: van de allereerste git init tot een gestroomlijnde deployment. Praktisch, concreet en direct toepasbaar.

De basis: een repository opzetten met git init

Alles begint met een repository. Een Git-repository is simpelweg een map waarin Git alle wijzigingen bijhoudt. Je maakt er een aan met één commando:

git init mijn-project

Dit maakt een nieuwe map aan met daarin een verborgen .git-map — de kern van je repository. Werk je al in een bestaande projectmap? Dan initialiseer je Git direct ter plekke:

cd mijn-project
git init

Vervolgens koppel je een remote repository, bijvoorbeeld op GitHub of GitLab:

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

Nu is je lokale omgeving verbonden met een centrale plek. Dit is de basis van elke samenwerking en elke deployment.

Voordat je je eerste commit doet, is het slim om een .gitignore-bestand aan te maken. Dit bestand vertelt Git welke bestanden niet getrackt moeten worden — denk aan node_modules/, .env-bestanden met wachtwoorden, of build-artefacten. GitHub en GitLab bieden kant-en-klare .gitignore-templates per taaltype aan.

Commits, branches en de dagelijkse workflow

De kern van Git draait om commits. Een commit is een snapshot van je code op een bepaald moment. Je voegt bestanden toe aan de zogenoemde staging area en vervolgens sla je die snapshot op:

git add index.php
git commit -m "Voeg contactformulier toe aan homepage"

Wil je alle gewijzigde bestanden in één keer toevoegen?

git add .
git commit -m "Initiële projectstructuur"

Schrijf altijd betekenisvolle commit messages. "Fix bug" zegt niets. "Los race condition op in login-handler bij gelijktijdige sessies" zegt alles. Je toekomstige zelf — en je collega's — zullen je dankbaar zijn.

Branching: werk parallel zonder conflicten

Branches zijn één van de krachtigste functies van Git. Ze stellen je in staat om aan een feature of bugfix te werken zonder de hoofdtak (main of master) aan te raken. De standaard aanpak:

git checkout -b feature/gebruikerslogin

Je werkt nu op een aparte branch. Maak commits, test lokaal, en pas daarna merge je terug naar main. Wil je een gestructureerde branching-strategie? Dan is Git Flow een bewezen aanpak:

git flow init

Git Flow introduceert vaste branchnamen voor features, releases en hotfixes. Het is wat uitgebreider, maar voor teams met regelmatige releases is het een uitstekende structuur. Start een nieuwe feature zo:

git flow feature start gebruikerslogin

En sluit hem af met:

git flow feature finish gebruikerslogin

Voor kleinere projecten of solo-work is een simpele main + feature-branches aanpak meer dan voldoende.

Samenwerken via pull requests en merge requests

Wanneer je klaar bent met een feature, wil je die code laten reviewen voordat hij naar main gaat. Dat doe je via een pull request (GitHub) of een merge request (GitLab). Dit is niet alleen een technische stap — het is een kwaliteitscheck.

Via de GitHub CLI maak je een pull request direct vanuit je terminal:

gh pr merge

Dit commando mergt de pull request die gekoppeld is aan je huidige branch, interactief. Je kiest zelf of je wilt mergen, squashen of rebasen. GitLab-gebruikers doen hetzelfde met:

glab mr merge

Wil je een merge request aanmaken voor review, dan gebruik je:

glab mr create

Het reviewproces dwingt je om code bewust te bekijken. Kleine teams slaan dit weleens over, maar zelfs als je solo werkt is een pull request nuttig: het dwingt je te reflecteren op wat je precies hebt gewijzigd voordat het in productie belandt.

Conflicten oplossen

Merge-conflicten klinken eng, maar zijn normaal. Ze ontstaan wanneer twee branches dezelfde regels anders hebben aangepast. Git markeert de conflicterende secties in je bestand:

<<<<<<< HEAD
echo "Versie A";
=======
echo "Versie B";
>>>>>>> feature/nieuwe-functie

Jij beslist welke versie wint, of je combineert beide. Daarna voeg je het bestand toe en commit je:

git add conflict-bestand.php
git commit -m "Los merge-conflict op in uitvoerfunctie"

Van commit naar deployment: CI/CD met GitHub Actions

Een goede Git-workflow eindigt niet bij de merge — die is pas het begin van de deployment. Met CI/CD (Continuous Integration / Continuous Deployment) automatiseer je het proces van testen en deployen zodra code op main terechtkomt.

GitHub Actions is hiervoor een populaire keuze. Je beheert je workflows direct vanuit de CLI:

gh workflow view

Dit geeft je interactief inzicht in de laatste uitgevoerde jobs per workflow. Je ziet direct of een deployment geslaagd is of waar het fout ging.

Een eenvoudig voorbeeld van een GitHub Actions workflow voor een PHP-project:

name: Deploy naar productie
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Synchroniseer naar server
        run: rsync -avz ./ gebruiker@server:/var/www/html/

Iedere push naar main triggert nu automatisch een deployment. Geen handmatig FTP-en meer, geen vergeten bestanden. Je code gaat direct, herhaalbaar en traceerbaar live.

Praktische Git-tips voor dagelijks gebruik

• Commit vroeg, commit vaak. Kleine, gerichte commits zijn makkelijker te reviewen en terug te draaien dan grote blokken code.
• Gebruik git stash wanneer je snel moet wisselen van branch zonder halfklaar werk te committen: git stash push -m "WIP: loginformulier".
• Bekijk je geschiedenis met git log --oneline --graph voor een overzichtelijke weergave van je branches en commits.
• Gebruik tags voor releases: git tag -a v1.2.0 -m "Release versie 1.2.0" — zo weet je altijd welke commit overeenkomt met welke productieversie.
• Nooit pushen naar main zonder review — bescherm je hoofdbranch via branch protection rules op GitHub of GitLab.
• Schrijf een goede README en documenteer je Git-conventies (branchnaming, commit-stijl). Nieuwkomers in het team bedanken je.

Conclusie: Git is de ruggengraat van je development-proces

Van git init tot een geautomatiseerde deployment — Git is het bindweefsel van moderne softwareontwikkeling. Het geeft je controle over je codebase, maakt samenwerking schaalbaar en zorgt ervoor dat je met vertrouwen kunt deployen.

De kernpunten op een rij:

• Begin elk project met git init en een doordachte .gitignore.
• Werk met branches — houd main stabiel en deployable.
• Gebruik pull requests of merge requests als kwaliteitspoort, ook solo.
• Automatiseer je deployment met CI/CD via GitHub Actions of GitLab Pipelines.
• Schrijf betekenisvolle commit messages — je documenteert je eigen werk.

Git is geen tool die je "een keer leert" en daarna klaar mee bent. Het is een vaardigheid die je verfijnt met elk project. Maar met deze basis ben je direct productiever, werkt je team soepeler samen, en slaap je rustiger wetende dat elke deployment traceerbaar en terugdraaibaar is.

```json

```