🔍

smsak.be/Claude-masterclass/Deel 7

GitHub

Git-basis, repositories, branches, GitHub Actions en code review met Claude.

Deel 7 van 12 § 37–41 · 5 secties Laatst nagekeken op
§ 37 — GitHub

GitHub: Alles wat je moet weten

GitHub is het grootste platform ter wereld voor code beheer en samenwerking. Voor Claude Code gebruikers is GitHub de schakel tussen lokaal ontwikkelen en live deployen via Vercel.

Kernconcepten visueel

📦

Repository

De "map in de cloud" met alle code en volledige geschiedenis. Elke wijziging ooit gemaakt is terugvindbaar.

📸

Commit

"Snapshot" op een moment — met auteur, datum en beschrijving. Vergelijk met AutoSave + notitie. Onmogelijk te verliezen als het eenmaal gecommit is.

🌿

Branch

Parallelle werklijn. main is altijd stabiel/productie. Features bouw je op aparte branches om main te beschermen.

⬆️

Push

Lokale commits uploaden naar GitHub. Pas na een push staan ze online en zijn ze door teamleden zichtbaar.

⬇️

Pull

De laatste wijzigingen van GitHub ophalen naar je lokale computer. Altijd doen vóór je start met werken.

🔄

Pull Request (PR)

Formeel verzoek om branch samen te voegen met main. Ingebouwde codereview, discussies en goedkeuringsflow.

🍴

Fork

Kopie van andermans repo onder jouw account. Basis van open source: fork → verbeter → stuur PR terug.

📋

Clone

Een GitHub repo downloaden naar je computer inclusief volledige geschiedenis. Eenmalig per project.

De Git Data Flow — Visueel

Git Flow — van code naar GitHubConcept
Jouw computer                           GitHub (cloud)
──────────────────────────────────────────────────────
Working Directory                       Remote Repository
  ↓ git add                               ↑ git push
Staging Area (Index)                    Origin/main
  ↓ git commit                            ↑
Local Repository ─────────────────────────
  ← git pull (fetch + merge)
  ← git fetch (alleen downloaden, nog niet samenvoegen)

Essentiële git commando's — Cheatsheet

CommandoFunctie
git statusZie welke bestanden gewijzigd zijn en wat klaarstaat om te committen
git log --onelineOverzicht van alle commits (kort)
git diffZie exacte wijzigingen regel per regel
git diff HEAD~1Vergelijk met vorige commit
git stashTijdelijk opbergen van niet-klare wijzigingen
git stash popStashed wijzigingen terugzetten
git restore [bestand]Bestand terugzetten naar laatste commit staat
git reset --soft HEAD~1Laatste commit ongedaan maken (wijzigingen bewaren)
git revert [hash]Een commit terugdraaien via een nieuwe commit (veilig)
git blame [bestand]Wie schreef welke regel?
§ 38 — GitHub

Een Compleet Project op GitHub Zetten

Dit is de volledige setup van een codeproject op GitHub — van nul tot gedeelde repository, inclusief alle best practices.

Stap 1: GitHub Account en SSH Key instellen

Terminal — Eenmalige SetupBash
# Configureer je naam en email (eenmalig)
git config --global user.name "Jouw Naam"
git config --global user.email "jij@email.be"
git config --global core.editor "code --wait"  # VS Code als editor

# Genereer SSH sleutel (veiliger dan wachtwoord)
ssh-keygen -t ed25519 -C "jij@email.be"
# Druk Enter (accepteer standaardlocatie)

# Kopieer je publieke sleutel
cat ~/.ssh/id_ed25519.pub
# Ga naar GitHub → Settings → SSH Keys → New SSH Key
# Plak de output hierboven

# Test de verbinding
ssh -T git@github.com

Stap 2: Nieuw Project Initialiseren

Terminal — Nieuw projectBash
# Optie A: Start lokaal, push naar GitHub
mkdir mijn-project && cd mijn-project
git init
git branch -M main  # Zorg dat hoofdbranch 'main' heet

# Optie B: Start vanuit GitHub (aanbevolen)
# Maak repo aan op github.com → "New Repository"
# Vink "Add README" aan, kies licentie
git clone git@github.com:gebruiker/mijn-project.git
cd mijn-project

Stap 3: .gitignore instellen (Verplicht!)

Het .gitignore bestand vertelt Git welke bestanden NIET te tracken. API keys, node_modules en build-output horen nooit op GitHub.

.gitignore — Next.js projectText
# Afhankelijkheden
node_modules/
.pnp
.pnp.js

# Build output
.next/
out/
dist/
build/

# Environment variabelen — NOOIT uploaden!
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
*.env

# Vercel deployment cache
.vercel

# Logs
npm-debug.log*
yarn-error.log

# OS bestanden
.DS_Store
Thumbs.db

# IDE bestanden
.vscode/settings.json
.idea/

Stap 4: Eerste Push naar GitHub

Terminal — Eerste pushBash
# Voeg alle bestanden toe (behalve wat in .gitignore staat)
git add .

# Controleer wat er toegevoegd wordt
git status

# Eerste commit maken
git commit -m "feat: initieel project met basisstructuur"

# Verbind lokale repo met GitHub remote
git remote add origin git@github.com:gebruiker/mijn-project.git

# Push naar GitHub (-u instelt tracking voor toekomstige pushes)
git push -u origin main

# Daarna is gewoon 'git push' genoeg
🚨
API keys op GitHub = Beveiligingsrisico Bots scannen GitHub 24/7 op gelekte API keys. Als je ooit per ongeluk een .env hebt gecommit: draai onmiddellijk alle betrokken sleutels in (Anthropic Console, Vercel, etc.) en verwijder ze uit de git history met git filter-branch of BFG Repo Cleaner.
💡
GitHub CLI (gh) — Werken zonder browser Installeer gh via brew install gh (Mac) of winget install GitHub.cli (Windows). Dan: gh repo create mijn-project --public --source=. --push maakt de repo aan en pusht in één commando.
§ 39 — GitHub

Branches, Mergen en Conflicten Oplossen

Branches zijn de kern van professioneel Git gebruik. Ze laten teams parallel werken zonder elkaar te blokkeren.

Git Branch Workflow — Visueel Diagram

Git-branchdiagram: main met twee feature-branches die terug gemergd worden en daarna deployen git init / clone git checkout -b feature/x git merge / PR merge vercel deploy main init v1.0 feature/login commit 1 commit 2 commit 3 merge feature/payment merge 🚀 live Pull Request ✓

Branching Strategie: GitHub Flow

De aanbevolen strategie voor de meeste projecten — eenvoudig maar krachtig:

GitHub Flow — Complete cyclusBash
── STAP 1: Haal altijd de laatste versie op voordat je begint ──
git checkout main
git pull origin main

── STAP 2: Maak een beschrijvende feature branch ──
git checkout -b feature/betalingssysteem-stripe
# of: git switch -c feature/betalingssysteem-stripe (moderne syntax)

── STAP 3: Werk aan de feature (meerdere kleine commits) ──
# ... code schrijven met Claude Code ...
git add .
git commit -m "feat: voeg Stripe checkout integratie toe"
# ... meer code ...
git add .
git commit -m "feat: voeg webhook handler toe voor betalingsbevestiging"

── STAP 4: Push branch naar GitHub ──
git push -u origin feature/betalingssysteem-stripe

── STAP 5: Maak Pull Request aan op GitHub (of via CLI) ──
gh pr create --title "feat: Stripe betalingssysteem" --body "Voegt Stripe toe voor..."

── STAP 6: Na review en goedkeuring: Merge naar main ──
gh pr merge --squash  # Squash: alle commits samenvoegen tot één

── STAP 7: Opruimen ──
git checkout main
git pull origin main
git branch -d feature/betalingssysteem-stripe  # Verwijder lokale branch
git push origin --delete feature/betalingssysteem-stripe  # Verwijder remote branch

Push en Pull — Alles wat je moet weten

CommandoWat het doetWanneer gebruiken
git pushLokale commits naar GitHub sturenNa elke sessie afwerken
git push -u origin [branch]Push + stel tracking inEerste keer een nieuwe branch pushen
git push --force-with-leaseGeforceerde push (veilig)Na rebase of reset — NOOIT op main!
git pullFetch + automatisch mergenElke ochtend voor je begint
git pull --rebaseFetch + rebase in plaats van mergeCleaner history bij teamwerk
git fetch originDownloaden zonder te mergenKijken wat er veranderd is
git fetch --all --pruneAlle remotes, verwijder stale refsOpruimen na veel branchwerk

Merge vs Rebase — Wanneer wat?

⚡ Merge (standaard)

git merge feature/login
Combineert branches via een "merge commit". Bewaart de volledige branch-geschiedenis. Aanbevolen voor publieke branches en samenwerking.

🎯 Rebase (gevorderden)

git rebase main
Plaatst je commits bovenop main — alsof je feature altijd al na main was. Geeft een lineaire, cleane history. Gebruik NOOIT op gedeelde/publieke branches.

Conflicten Oplossen — Stap voor Stap

Een conflict treedt op als dezelfde regels in twee branches anders zijn gewijzigd. Git weet niet welke versie te kiezen.

Terminal + Editor — Conflict oplossenBash
# Conflict treedt op bij merge/pull:
git pull origin main
# CONFLICT (content): Merge conflict in src/app.js

# Bekijk welke bestanden conflicten hebben:
git status
# both modified: src/app.js

# Open het bestand — conflict markers zien er zo uit:
# <<<<<<< HEAD (jouw versie)
# const greeting = "Hallo wereld";
# =======
# const greeting = "Hello world";
# >>>>>>> origin/main (hun versie)

# Laat Claude Code het conflict oplossen:
> Er is een merge conflict in src/app.js. Los het op door
  de beste versie te kiezen of de twee samen te voegen.

# Nadat je het bestand hebt opgeslagen:
git add src/app.js
git commit -m "fix: los merge conflict op in greeting string"

Conventional Commits — Complete Gids

Vraag Claude altijd commit messages te schrijven in het Conventional Commits format. Dit maakt automatische changelogs en semantic versioning mogelijk:

PrefixGebruik voorVoorbeeld
feat:Nieuwe functionaliteitfeat: voeg donkere modus toe
fix:Bug reparatiefix: herstel login redirect loop
docs:Documentatiedocs: update README installatie
style:Opmaak, geen logicastyle: pas button kleuren aan
refactor:Herstructureringrefactor: vereenvoudig auth module
perf:Performance verbeteringperf: optimaliseer database queries
test:Teststest: voeg unit tests toe voor cart
chore:Onderhoud, configschore: update dependencies
feat!:Breaking changefeat!: wijzig API authenticatie methode

Tags en Releases

Terminal — Versies taggenBash
# Maak een versie-tag (semantic versioning: major.minor.patch)
git tag -a v1.0.0 -m "Release 1.0.0: productie launch"
git push origin v1.0.0

# Alle tags zien:
git tag -l

# GitHub Release aanmaken via CLI:
gh release create v1.0.0 --title "v1.0.0 — Productie Launch" \
  --notes "Eerste stabiele release met alle core features"
§ 40 — GitHub

GitHub Actions: CI/CD Automatiseren

GitHub Actions laat je workflows automatisch uitvoeren bij events zoals push, PR of op schema. Claude schrijft deze YAML workflows voor je.

Complete CI/CD Pipeline voor Next.js

.github/workflows/ci-cd.ymlYAML
name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

env:
  NODE_VERSION: '20'

jobs:
  quality:
    name: Kwaliteitscheck
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'  # Cache npm voor snellere runs

      - name: Installeer dependencies
        run: npm ci  # ci is sneller en deterministischer dan install

      - name: TypeScript check
        run: npx tsc --noEmit

      - name: Linting
        run: npm run lint

      - name: Unit tests
        run: npm test -- --ci --coverage

      - name: Build productie
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

  security:
    name: Security Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Audit npm packages
        run: npm audit --audit-level=high
      - name: Claude Code Security Review
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Review deze code wijzigingen op beveiligingsproblemen. Focus op OWASP top 10."

GitHub Secrets instellen

1

Ga naar je repo Settings

GitHub repo → Settings → Secrets and variables → Actions → New repository secret

2

Voeg secrets toe

Elke geheime waarde (API keys, wachtwoorden) die je workflows nodig hebben. Ze worden nooit zichtbaar in logs.

3

Gebruik in workflows

Refereer als ${{ secrets.MIJN_SECRET }} in je YAML — nooit de waarde hardcoden.

💡
Laat Claude je Actions schrijven "Schrijf een GitHub Actions workflow die bij elke push naar main: 1) TypeScript checkt, 2) tests draait, 3) naar Vercel deployt, 4) een Slack bericht stuurt met de deploymentstatus." — Claude schrijft het complete YAML bestand.
§ 41 — GitHub

Pull Requests en Code Review met Claude

Een goede PR workflow is de basis van kwaliteitsvolle code. Claude Code kan direct als reviewer ingesteld worden via de officiële GitHub Action.

Claude als Automatische Code Reviewer

Voeg de officiële Claude Code GitHub Action toe en Claude reviewt automatisch elke PR:

.github/workflows/claude-review.ymlYAML
name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          direct_prompt: |
            Review deze PR op:
            - Beveiligingsproblemen (SQL injectie, XSS, auth lekken)
            - Performance issues
            - Code kwaliteit en leesbaarheid
            - Ontbrekende error handling
            Geef inline PR comments in het Nederlands.

Handmatige Code Review Prompts

🔍 Deep Code Review
Review de volgende code op: 1. Beveiligingsproblemen (SQL injectie, XSS, CSRF, authenticatie lekken) 2. Performance bottlenecks (N+1 queries, onnodige re-renders, memory leaks) 3. Code kwaliteit (SOLID principes, DRY, naamgeving, complexiteit) 4. Ontbrekende foutafhandeling en edge cases 5. Mogelijke race conditions of concurrency problemen Geef per probleem: beschrijving, ernst (Kritisch/Hoog/Midden/Laag), concrete fix met code. [PLAK CODE HIER]
📋 PR Beschrijving Generator
Genereer een professionele Pull Request beschrijving op basis van deze git diff. De beschrijving moet bevatten: - Samenvatting (2-3 zinnen over WAAROM, niet wat) - Type wijziging: feat/fix/refactor/perf/security - Lijst van specifieke veranderingen - Testinstructies: hoe verifieer ik dat dit werkt? - Breaking changes: ja/nee + uitleg - Gerelateerde issues: sluit #[nummer] [PLAK GIT DIFF: git diff main...feature/branch]

PR Workflow Best Practices

  • Branch up-to-date met main vóór PR aanmaken (git pull --rebase origin main)
  • PR beschrijving duidelijk: WAAROM deze wijziging, niet alleen WAT
  • Kleine PRs: max 400 regels gewijzigde code — grote PRs worden slecht gereviewd
  • Screenshots/video voor UI wijzigingen bijvoegen
  • Alle CI checks groen vóór je reviewers vraagt
  • Squash mergen voor een cleane main history
  • Van SMSAK

    Liever samen doorlopen dan alleen lezen?

    SMSAK geeft on-site Claude-masterclasses en bouwt software op maat met Claude Code. We vertrekken van je eigen processen en bestanden — geen algemene demo.