Git voor ontwikkelaars: 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 u 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 doorloopt u 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. U 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 uw repository. Werkt u al in een bestaande projectmap? Dan initialiseert u Git direct ter plekke:

cd mijn-project
git init

Vervolgens koppelt u een remote repository, bijvoorbeeld op GitHub of GitLab:

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

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

Voordat u uw eerste commit doet, is het verstandig 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 uw code op een bepaald moment. U voegt bestanden toe aan de zogenaamde staging area en vervolgens slaat u die snapshot op:

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

Wilt u 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. Uw toekomstige zelf — en uw collega's — zullen u dankbaar zijn.

Branching: werk parallel zonder conflicten

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

git checkout -b feature/gebruikerslogin

U werkt nu op een aparte branch. Maak commits, test lokaal, en pas daarna merged u terug naar main. Wilt u een gestructureerde branching-strategie? Dan is Git Flow een beproefde 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-werk is een simpele main + feature-branches aanpak meer dan voldoende.

Samenwerken via pull requests en merge requests

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

Via de GitHub CLI maakt u een pull request rechtstreeks vanuit uw terminal:

gh pr merge

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

glab mr merge

Wilt u een merge request aanmaken voor review, dan gebruikt u:

glab mr create

Het reviewproces dwingt u om code bewust te bekijken. Kleine teams slaan dit weleens over, maar zelfs als u solo werkt is een pull request nuttig: het dwingt u te reflecteren op wat u 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 uw bestand:

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

U beslist welke versie wint, of u combineert beide. Daarna voegt u het bestand toe en committed u:

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) automatiseert u het proces van testen en deployen zodra code op main terechtkomt.

GitHub Actions is hiervoor een populaire keuze. U beheert uw workflows rechtstreeks vanuit de CLI:

gh workflow view

Dit geeft u interactief inzicht in de laatste uitgevoerde jobs per workflow. U ziet direct of een deployment geslaagd is of waar het fout liep.

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. Uw 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 u snel moet wisselen van branch zonder halfafgewerkt werk te committen: git stash push -m "WIP: loginformulier".
• Bekijk uw geschiedenis met git log --oneline --graph voor een overzichtelijke weergave van uw branches en commits.
• Gebruik tags voor releases: git tag -a v1.2.0 -m "Release versie 1.2.0" — zo weet u altijd welke commit overeenkomt met welke productieversie.
• Nooit pushen naar main zonder review — bescherm uw hoofdbranch via branch protection rules op GitHub of GitLab.
• Schrijf een goede README en documenteer uw Git-conventies (branchnaming, commit-stijl). Nieuwkomers in het team bedanken u.

Conclusie: Git is de ruggengraat van uw development-proces

Van git init tot een geautomatiseerde deployment — Git is het bindweefsel van moderne softwareontwikkeling. Het geeft u controle over uw codebase, maakt samenwerking schaalbaar en zorgt ervoor dat u 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 uw deployment met CI/CD via GitHub Actions of GitLab Pipelines.
• Schrijf betekenisvolle commit messages — u documenteert uw eigen werk.

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