Claude Code en GitHub: van lokale wijziging naar pull request

Een lokale wijziging kan er goed uitzien en toch iets breken zodra ze bij de rest van een project komt. GitHub helpt om het voorstel, de controles en de beslissing tot samenvoegen bij elkaar te houden. Claude Code kan bij dat werk helpen, maar bepaalt niet vanzelf wie publicatierechten hoort te hebben.

Het begint met een onderscheid: gebruik je Claude Code op je eigen computer, laat je een GitHub Action draaien of gebruik je een beheerde dienst? De naam lijkt op elkaar; de plaats van uitvoering en de bevoegdheden kunnen flink verschillen.

De officiële GitHub Actions-documentatie onderscheidt de Action van onder meer Code Review en Claude Code in de cloud. Kies eerst welke route je bedoelt.

Een lokale sessie installeren verbindt je repository niet automatisch met een Action. Andersom zegt een geïnstalleerde GitHub App nog niet dat ieder gewenst workflowgedrag aanstaat. Kijk naar de daadwerkelijk ingerichte route en de toegang die erbij hoort.

Werk eerst vast waar de juiste repository staat en welke remote erbij hoort. Open de projectmap die bij die repository hoort. Controleer bestaande wijzigingen voordat je Claude aan een nieuwe taak laat beginnen; andermans onaf werk hoort niet ongemerkt bij jouw voorstel.

Kies een eigen werkbranch op de afgesproken basis van het project. Bij een project met een integratiebranch hoort een feature daarheen; een release naar productie is een aparte beslissing. Vraag Claude de actieve branch en betrokken bestanden te benoemen voordat je laat schrijven.

De workflowdocumentatie beschrijft werken aan wijzigingen en pull requests met Claude Code. Mijn voorkeur is één samenhangend resultaat per voorstel. Een kleine fout herstellen en tegelijk de hele projectstructuur veranderen maakt de beoordeling onnodig lastig.

Je Claude-login en je GitHub-toegang zijn verschillende bevoegdheden. De een laat je het bouwgereedschap gebruiken; de ander kan toegang geven tot repositories of het pushen van commits. Geef niet automatisch alle repositories vrij omdat je één project wilt aanpassen.

Een pull request stelt wijzigingen voor aan een doelbranch. GitHub brengt daar onder meer de beschrijving, commits, checks en bestandsverschillen samen. Een concept-PR kan onaf werk zichtbaar maken zonder al klaar voor merge te zijn.

Laat Claude een beschrijving maken die het probleem en het nieuwe gedrag uitlegt. Voeg de uitgevoerde controles toe en noem wat nog niet is gecontroleerd. Controleer de tekst zelf: een opdracht om een test uit te voeren is geen bewijs dat die test is geslaagd.

Bekijk vóór het maken van de PR de gekozen doelbranch en de volledige diff. Een onverwacht bestand kan wijzen op meegekomen werk. Een merge naar de verkeerde branch kan je normale integratieproces overslaan. Goedkeuring hoort vervolgens bij de actuele inhoud van het voorstel.

Stel dat je team uit een interne app een CSV-export haalt. Twee kolommen hebben vrijwel dezelfde naam. Je wilt de koppen verduidelijken, maar de gegevens en kolomvolgorde behouden omdat collega’s ze in een spreadsheet verwerken.

Maak die afspraak het begin van de taak: alleen de kopteksten veranderen. Laat Claude op de werkbranch vinden waar de export wordt samengesteld en of andere onderdelen dezelfde koppen gebruiken. Vraag ook welke tests al bestaan. Zo zie je of een ogenschijnlijk cosmetische wijziging een afhankelijkheid raakt.

Laat de test een klein fictief exportbestand controleren: nieuwe koppen, dezelfde volgorde en dezelfde waarden. Controleer daarna zelf een voorbeeldbestand in de gebruikelijke spreadsheetsoftware. Gebruik daarvoor geen echte klantdata. De test kan de technische structuur afdekken, terwijl jij nagaat of de labels voor een collega begrijpelijk zijn.

Bekijk de diff en laat de wijziging pas daarna vastleggen en pushen naar de afgesproken werkbranch. De PR-beschrijving vermeldt welke koppen veranderen en waarom de kolomvolgorde behouden blijft. Voeg de concrete testuitslag toe en meld of de spreadsheetcontrole is gedaan.

De reviewer bekijkt vervolgens ook de gebruiksafspraak. Misschien blijkt dat een bestaande spreadsheet formules op kolomnamen baseert. Dan vraagt dit werk om een afgestemde overgang, ook als alle geautomatiseerde tests groen zijn. Het gesprek op de PR maakt die consequentie zichtbaar voordat de wijziging wordt samengevoegd.

Wil je Claude vanuit een issue of PR laten werken, beoordeel dan eerst of de Action past binnen het repositorybeleid en budget. De officiële installatieopdracht /install-github-app heeft administratieve gevolgen: ze kan een app installeren, authenticatie opslaan en een workflowvoorstel voorbereiden. Dit is geen vrijblijvende lokale test.

Gebruik voor repositorywerk passende gebeurtenissen, zoals een issuevermelding of pull request. Bepaal wie zo’n run mag starten en welke informatie erin terechtkomt. Een tekst in een extern issue is invoer die je beoordeelt, geen vrijbrief voor ruimere bevoegdheden.

Volgens GitHubs uitleg over GITHUB_TOKEN hoort een Action alleen de minimaal benodigde rechten te krijgen. Lees daarom zowel apprechten als workflowrechten. Houd geheimen in het daarvoor bedoelde beheer en druk ze niet af in uitvoer.

Een achtergrondtaak uit je bedrijfsapp hoort bovendien bij het platform dat haar uitvoert. Een dagelijkse import of klantmailronde is geen reden om naast je app een GitHub-tijdschema te bouwen. Gebruik GitHub hier voor repositorygebeurtenissen en controles.

Spreek af wie mag samenvoegen en welke checks daarvoor moeten slagen. Een aanbeveling van Claude is geen zelfstandig releasebesluit. Controleer na samenvoegen ook de uitrol volgens je projectprocedure; een gesloten PR bewijst nog niet welke versie gebruikers zien.

Begin je met de lokale route, gebruik dan onze Claude Code-handleiding. Wil je dit proces oefenen met een eigen app, bekijk de Vibe Coding Training. Neem daarbij vooral de vraag mee wie jouw wijziging beoordeelt en op basis van welk bewijs.