Wat we ermee bouwen
Git is geen voorkeur, het is de ondergrond — maar hóé een team het gebruikt is een echte keuze, en die is terug te zien in hoe makkelijk een codebase een jaar later te bewerken valt.
Onze standaard is kortlevende branches vanaf een trunk die altijd bouwt, één beoordeelde pull request per wijziging, en CI die tests, lint en een build draait bij elke push. Commits schrijven we om gelezen te worden: een bericht dat uitlegt waarom, geen herhaling van de diff.
Waar het past
Bij elke opdracht, ook bij werk in de eigen repository van een klant. Sluiten we via teamuitbreiding aan bij een bestaand team, dan nemen we hun branchingmodel en reviewafspraken over in plaats van de onze op te leggen — consistentie binnen één repo is meer waard dan dat een bepaalde workflow objectief beter is.
Wanneer we het aanraden
Voor de werkwijze hierboven: trunk-based ontwikkelen met kleine branches die vaak samengevoegd worden. Langlevende featurebranches zijn waar mergepijn en verouderde code vandaan komen, en de rekening komt weken na het besluit dat hem veroorzaakte.
Waar we tegenin gaan, is proces om het proces — verplicht squashen, starre formaten voor commitberichten, of een branchingmodel met vijf permanente branches in een team van drie. Het doel is een historie die je kunt bisecten en een review die iets vangt, geen ceremonie.