Atomiske commits og endringer på tvers av prosjekter

En atomisk commit representerer én enkelt, komplett og uavhengig logisk endring i kodebasen. Tenk på den som en liten, selvstendig arbeidsenhet.

Det betyr at en commit enten skal lykkes i sin helhet eller mislykkes i sin helhet, uten å etterlate repositoriet i en inkonsistent tilstand. Dette gjør det enklere å forstå og håndtere prosjektets historikk.

Atomiske commits har flere viktige fordeler:

• Enklere koderevisjon: De som gjennomgår koden, kan konsentrere seg om én bestemt endring om gangen.
• Enklere tilbakerulling: Hvis en endring introduserer en feil, er det enkelt å rulle den tilbake.
• Tydeligere historikk: Hver commit forteller en sammenhengende historie, noe som gjør prosjektets historikk enklere å navigere i.
• Bedre feilsøking: Verktøy som git bisect er mer effektive med atomiske endringer.

For å opprette atomiske commits bør du konsentrere deg om å commite én logisk endring om gangen. Det kan innebære å:

• Fikse én enkelt feil.
• Legge til én bestemt funksjon.
• Refaktorere én bestemt funksjon.

Unngå å blande urelaterte endringer, som en feilretting og en ny funksjon, i samme commit.

Se for deg at du arbeider med en fil som har to urelaterte endringer: en feilretting og en ny funksjon. I stedet for én stor commit lager du to:

# 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"

Ved å bruke git add -p (patch-modus) kan du stage bestemte deler av en fil.

I et monorepo påvirker én enkelt logisk funksjon eller feilretting ofte flere gjensidig avhengige prosjekter eller pakker. Hvis et delt hjelpebibliotek for eksempel oppdateres, kan det være nødvendig å endre flere applikasjoner som bruker det.

Dette kalles endringer på tvers av prosjekter, og de krever nøye koordinering for å opprettholde stabiliteten.

Den største utfordringen med endringer på tvers av prosjekter er å sikre at alle relaterte endringer gjøres og lanseres samlet. Hvis en endring i ett prosjekt ødelegger et annet, kan det føre til:

• Bygg som feiler
• Feil under kjøring
• Inkonsistent oppførsel

Dette gjelder spesielt når komponentene er tett koblet.

Når du gjør endringer på tvers av prosjekter, bør du sikte mot én omfattende commit eller en serie logisk sammenknyttede atomiske commits. Denne tilnærmingen sikrer at:

• Alle avhengige deler oppdateres samtidig.
• Hele endringen kan gjennomgås under ett.
• Det er mulig å rulle tilbake hele funksjonen ved behov.

Dette opprettholder det atomiske prinsippet på tvers av flere prosjekter.

Ved endringer på tvers av prosjekter er ikke enhetstester for individuelle komponenter nok. Du må kjøre integrasjonstester som dekker alle berørte prosjekter.

Det innebærer å kontrollere at den oppdaterte delte komponenten fungerer riktig sammen med alle konsumentene, og at funksjonaliteten til konsumentene fortsatt er intakt.

For svært omfattende eller risikable endringer på tvers av prosjekter bør du vurdere strategier som feature flags eller trinnvis utrulling.

• Feature flags: Lar deg distribuere koden, men bare aktivere den nye funksjonaliteten for bestemte brukere eller miljøer.
• Trinnvis utrulling: Endringene lanseres gradvis til en liten prosentandel av brukerne før en full lansering.

Disse teknikkene bidrar til å redusere risikoen og gjør det mulig å rulle raskt tilbake hvis det oppstår problemer.

I denne leksjonen utforsket vi atomiske commits og hvor viktige de er for en tydelig historikk og enkel tilbakerulling. Vi lærte også om utfordringene ved endringer på tvers av prosjekter i monorepoer.

De viktigste punktene er å lage enkeltstående, logiske commits, koordinere endringer mellom gjensidig avhengige prosjekter og bruke integrasjonstesting for å sikre stabilitet. Denne praksisen sørger for en sunn og håndterbar monorepo-kodebase.