Atomiset commitit ja projektien väliset muutokset

Atominen commit sisältää yhden täydellisen ja itsenäisen loogisen muutoksen koodikantaan. Sitä voi ajatella pienenä, itsenäisenä työyksikkönä.

Tämä tarkoittaa, että commitin tulee joko onnistua kokonaan tai epäonnistua kokonaan jättämättä repositoriota epäjohdonmukaiseen tilaan. Se helpottaa projektin historian ymmärtämistä ja hallintaa.

Atomisilla commitilla on useita keskeisiä etuja:

• Helpompi koodin katselmointi: Katselmoijat voivat keskittyä yhteen tiettyyn muutokseen kerrallaan.
• Yksinkertaisempi palautus: Jos muutos aiheuttaa virheen, sen palauttaminen on suoraviivaista.
• Selkeämpi historia: Jokainen commit kertoo johdonmukaisen tarinan, mikä helpottaa projektin historiassa navigointia.
• Parempi virheenkorjaus: git bisect -komennon kaltaiset työkalut toimivat tehokkaammin atomisten muutosten kanssa.

Luodaksesi atomisia committeja keskity yhden loogisen muutoksen commitoimiseen kerrallaan. Tämä voi tarkoittaa esimerkiksi seuraavaa:

• yhden virheen korjaaminen
• yhden tietyn ominaisuuden lisääminen
• tietyn funktion refaktorointi

Vältä toisiinsa liittymättömien muutosten, kuten virheenkorjauksen ja uuden ominaisuuden, yhdistämistä samaan committiin.

Oletetaan, että käsittelet tiedostoa, jossa on kaksi toisiinsa liittymätöntä muutosta: virheenkorjaus ja uusi ominaisuus. Yhden suuren commitin sijaan tekisit kaksi:

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

git add -p -komennon (patch-tilan) avulla voit valmistella tiettyjä tiedoston osia commitoitaviksi.

Monorepossa yksi looginen ominaisuus tai virheenkorjaus vaikuttaa usein useisiin toisistaan riippuvaisiin projekteihin tai paketteihin. Esimerkiksi jaetun utility-kirjaston päivittäminen voi edellyttää muutoksia useissa sitä käyttävissä sovelluksissa.

Näitä kutsutaan projektien välisiksi muutoksiksi, ja niiden vakaana pitämiseen tarvitaan huolellista koordinointia.

Projektien välisten muutosten suurin haaste on varmistaa, että kaikki niihin liittyvät muutokset tehdään ja julkaistaan yhdessä. Jos yhden projektin muutos rikkoo toisen, seurauksena voi olla:

• rikkoutuneita koonteja
• ajonaikaisia virheitä
• epäjohdonmukaista toimintaa

Tämä koskee erityisesti tilanteita, joissa komponentit ovat tiukasti sidoksissa toisiinsa.

Kun teette projektien välisiä muutoksia, pyrkikää yhteen kattavaan committiin tai loogisesti linkitettyjen atomisten commitien sarjaan. Näin varmistetaan, että:

• kaikki riippuvaiset osat päivitetään samanaikaisesti
• koko muutos voidaan katselmoida yhtenä kokonaisuutena
• koko ominaisuus voidaan tarvittaessa palauttaa

Näin atominen periaate säilyy useissa projekteissa.

Projektien välisissä muutoksissa yksittäisten komponenttien yksikkötestit eivät riitä. Teidän on suoritettava integroituja testejä, jotka kattavat kaikki muutoksesta vaikuttuvat projektit.

Tämä tarkoittaa, että varmistetaan päivitetyn jaetun komponentin toimivan oikein kaikkien sitä käyttävien komponenttien kanssa ja että niiden toiminnallisuus säilyy ennallaan.

Erittäin suurissa tai riskialttiissa projektien välisissä muutoksissa kannattaa harkita strategioita, kuten feature flageja tai vaiheittaisia julkaisuja.

• Feature flagit: Niiden avulla koodi voidaan ottaa käyttöön, mutta uusi toiminnallisuus voidaan sallia vain tietyille käyttäjille tai ympäristöille.
• Vaiheittaiset julkaisut: Muutokset julkaistaan ensin vähitellen pienelle osalle käyttäjistä ennen täyttä julkaisua.

Nämä tekniikat auttavat pienentämään riskiä ja mahdollistavat nopean palautuksen, jos ongelmia ilmenee.

Tässä oppitunnissa tarkastelimme atomisia committeja ja niiden merkitystä selkeälle historialle ja helpolle palauttamiselle. Opimme myös monorepojen projektien välisten muutosten haasteista.

Keskeisiä oppeja ovat yksittäisten loogisten commitien laatiminen, toisistaan riippuvien muutosten koordinointi ja integroidun testauksen käyttö vakauden varmistamiseksi. Näillä käytännöillä monorepon koodikanta pysyy hyväkuntoisena ja hallittavana.