Atomaire commits en wijzigingen tussen projecten

Een atomische commit vertegenwoordigt één volledige, onafhankelijke logische wijziging in je codebasis. Zie het als een kleine, zelfstandige werkeenheid.

Dit betekent dat een commit volledig moet slagen of volledig moet mislukken, zonder de repository in een inconsistente toestand achter te laten. Zo wordt het eenvoudiger om de geschiedenis van je project te begrijpen en te beheren.

Atomische commits bieden verschillende belangrijke voordelen:

• Eenvoudigere codebeoordeling: beoordelaars kunnen zich telkens op één specifieke wijziging richten.
• Eenvoudiger terugdraaien: als een wijziging een fout introduceert, kun je die eenvoudig terugdraaien.
• Duidelijkere geschiedenis: elke commit vertelt een samenhangend verhaal, waardoor je eenvoudiger door de projectgeschiedenis navigeert.
• Beter fouten opsporen: hulpmiddelen zoals git bisect werken effectiever met atomische wijzigingen.

Richt je bij het maken van atomische commits op één logische wijziging per keer. Dat kan bijvoorbeeld betekenen:

• één fout oplossen;
• één specifieke functie toevoegen;
• een specifieke functie herstructureren.

Vermijd het combineren van niet-gerelateerde wijzigingen, zoals een foutoplossing en een nieuwe functie, in dezelfde commit.

Stel dat je werkt aan een bestand met twee niet-gerelateerde wijzigingen: een foutoplossing en een nieuwe functie. In plaats van één grote commit maak je er twee:

# Stage only the bug fix
git add -p my_file.js
git commit -m "Fix: Display error on form submission"

# Stage only the new feature
git add -p my_file.js
git commit -m "Feat: Add user profile picture upload"

Met git add -p (patchmodus) kun je specifieke delen van een bestand klaarzetten.

In een monorepo heeft één logische functie of foutoplossing vaak gevolgen voor meerdere onderling afhankelijke projecten of pakketten. Als je bijvoorbeeld een gedeelde hulpprogrammabibliotheek bijwerkt, zijn mogelijk wijzigingen nodig in verschillende toepassingen die deze bibliotheek gebruiken.

Dit worden wijzigingen in meerdere projecten genoemd. Ze vereisen zorgvuldige coördinatie om de stabiliteit te behouden.

De grootste uitdaging bij wijzigingen in meerdere projecten is ervoor zorgen dat alle gerelateerde aanpassingen samen worden doorgevoerd en uitgebracht. Als een wijziging in het ene project een ander project breekt, kan dat leiden tot:

• mislukte builds;
• fouten tijdens runtime;
• inconsistent gedrag.

Dit geldt vooral wanneer componenten sterk van elkaar afhankelijk zijn.

Streef bij wijzigingen in meerdere projecten naar één uitgebreide commit of een reeks logisch verbonden atomische commits. Deze aanpak zorgt ervoor dat:

• alle afhankelijke onderdelen gelijktijdig worden bijgewerkt;
• de volledige wijziging als geheel kan worden beoordeeld;
• de volledige functie indien nodig kan worden teruggedraaid.

Zo blijft het atomische principe behouden in meerdere projecten.

Bij wijzigingen in meerdere projecten zijn unit-tests voor afzonderlijke componenten niet voldoende. Je moet geïntegreerde tests uitvoeren die alle betrokken projecten omvatten.

Dit betekent dat je controleert of de bijgewerkte gedeelde component correct werkt met alle onderdelen die deze gebruiken en of de functionaliteit van die onderdelen intact blijft.

Overweeg bij zeer grote of risicovolle wijzigingen in meerdere projecten strategieën zoals functievlaggen of een gefaseerde uitrol.

• Functievlaggen: hiermee kun je de code implementeren, maar de nieuwe functionaliteit alleen inschakelen voor specifieke gebruikers of omgevingen.
• Gefaseerde uitrol: hiermee geef je de wijzigingen geleidelijk vrij aan een klein percentage gebruikers voordat je ze volledig uitrolt.

Deze technieken helpen risico's te beperken en maken snel terugdraaien mogelijk als er problemen ontstaan.

In deze les hebben we atomische commits en hun belang voor een duidelijke geschiedenis en eenvoudig terugdraaien besproken. Ook hebben we geleerd welke uitdagingen wijzigingen in meerdere projecten in monorepo's met zich meebrengen.

Belangrijke punten zijn het maken van afzonderlijke, logische commits, het coördineren van wijzigingen met onderlinge afhankelijkheden en het gebruiken van geïntegreerd testen voor stabiliteit. Deze werkwijzen zorgen voor een gezonde en beheersbare codebasis in een monorepo.