Interaktiivista rebasea kutsutaan joskus Gitin ”sveitsiläiseksi armeijan veitseksi” – koska se sisältää niin monia eri työkaluja niin moniin eri käyttötarkoituksiin! On kuitenkin yksi tärkein, kaiken kattava käyttötapaus: paikallisen commit-historian siivoaminen.

Muista sana ”paikallinen”: sitä tulisi käyttää vain oman, paikallisen commit-historian siivoamiseen, esimerkiksi ennen kuin integroit yhden feature-haarasi tiimihaaraan. Sitä vastoin sitä EI tulisi käyttää commit-historiaan, joka on jo siirretty ja jaettu etätietovarastoon. Interactive rebase on yksi niistä työkaluista, jotka ”kirjoittavat” Git-historiaa uudelleen – eikä sitä pitäisi tehdä kommitoinneille, jotka on jo jaettu muiden kanssa.

Kun tämä pieni varoitusviesti on saatu pois tieltä, katsotaanpa muutamia käytännön esimerkkejä!

Huomautus: tämän postauksen skenaarioiden ja työnkulkujen helpomman havainnollistamisen vuoksi olen käyttänyt ”Tower” Git-työpöytä-GUI:ta joissakin kuvakaappauksissani.

Vanhan commit-viestin korjaaminen

Joskus huomaat kirjoitusvirheen vanhassa commit-viestissä – tai olet unohtanut mainita kuvauksessa jotakin huomionarvoista. Jos puhuimme aivan viimeisestä toimituksesta, olisimme voineet yksinkertaisesti käyttää git commit-komennon --amend-vaihtoehtoa. Mutta vanhempien kommittien kohdalla sinun on käytettävä interaktiivista rebasea muuttaaksesi niitä jälkikäteen.

Tässä on esimerkki hirveästi pieleen menneestä komitusviestistä, jonka haluamme korjata:

Paha komitusviesti, joka kaipaa korjaustaPaha komitusviesti, joka kaipaa korjausta

Kaikkien interaktiivisten rebase-istuntojen ensimmäisenä askeleena on määritellä, mitä komitointihistorian osaa halutaan manipuloida. Otetaan taas yllä oleva esimerkki: voidaksemme muuttaa tätä huonoa commitia meidän on aloitettava istunto sen vanhemmasta commitista.

Vuorovaikutteisen rebase-istuntomme aloittaminenVuorovaikutteisen rebase-istuntomme aloittaminen

Voidaan nyt syöttää tämän aloittavan commitin hash interaktiiviselle rebase-komennolle:

$ git rebase -i 0023cddd

Toimitusikkuna aukeaa nyt, ja se sisältää luettelon juuri valitsemistasi manipuloitavaksi valittuna pidettävistä commiteista. Äläkä ihmettele, koska ne ovat käänteisessä järjestyksessä: interaktiivisessa rebase-istunnossa Git soveltaa vanhoja kommitteja uudelleen, kohde toisensa jälkeen – mikä tarkoittaa, että järjestyksen kääntäminen päinvastaiseksi on Gitin näkökulmasta oikein.

Editori-ikkuna, jossa on valitut kommititEditori-ikkuna, jossa on valitut kommitit

Yksi toinenkin tärkeä huomio tähän editori-ikkunaan liittyen: varsinaista manipulaatioita et suorita tässä! Tai, tässä konkreettisessa esimerkissä, et mene eteenpäin ja muuta commit-viestiä täällä. Sen sijaan merkitset vain sen commitin, jota haluat muuttaa action-avainsanalla. Meidän tapauksessamme, koska haluamme muuttaa commitin viestin, merkitsemme rivin sanalla ”reword”. Jos sitten tallennat ja suljet tämän editori-ikkunan, avautuu uusi ikkuna, joka sisältää vanhan commit-viestin. Nyt on vihdoin aika tehdä muutokset:

Vihdoin voimme tehdä muutoksemmeVihdoin voimme tehdä muutoksemme

Tallennuksen ja vielä kerran sulkemisen jälkeen interaktiivinen rebase-istunto on valmis, ja vanha commit-viestimme on korjattu!

Monien kommittien yhdistäminen yhdeksi

Toinen interaktiivisen rebase-istunnon käyttökohde on silloin, kun halutaan yhdistellä useampia vanhoja kommitointeja yhdeksi. Tosin tietysti versionhallinnan kultainen sääntö pätee: useimmissa tilanteissa on hyödyllistä luoda useampia ja pienempiä kommitteja muutaman suuren sijaan. Kuten kaikessa muussakin, saatamme kuitenkin huomata, että olemme liioitelleet ja haluamme nyt sulauttaa kaksi tai useampia vanhoja kommitteja yhdeksi.

Konkreettisen esimerkin vuoksi sanotaan, että haluamme yhdistää seuraavat valitut kommitit yhdeksi:

Yhdistetään useat kommitit yhdeksiYhdistetään useat kommitit yhdeksi

Aivan kuten ensimmäisessä tapauksessamme, aloitamme vuorovaikutteisen rebase-istunnon aloittamalla interaktiivisen uudelleenkäsittelyistunnon vähintään sen kommitin vanhemmasta kommitista (parent commit), jota haluamme manipuloida.

$ git rebase -i 2b504bee

Jälleen avautuu editori-ikkuna, joka listaa sen osan commit-historiastamme, jota haluamme manipuloida:

Merkitään rivit "squash"-merkinnällä Merkitään rivit ”squash”-merkinnällä

Toiminta-avainsanaa, jota aiomme käyttää tässä, kutsutaan nimellä ”squash”. Ja on vain yksi tärkeä tieto, joka sinun on tiedettävä squashista, jotta voit käyttää sitä: rivi, jonka merkitsemme avainsanalla ”squash”, yhdistetään suoraan sen yläpuolella olevaan riviin. Siksi, kuten näet yllä olevassa kuvakaappauksessani, olen merkinnyt rivin nro 2 ”squash”-merkinnällä yhdistääkseni sen riviin nro 1.

Voit nyt tallentaa ja sulkea editori-ikkunan ja taas katsella ja uusi ikkuna ilmestyy näkyviin: meitä pyydetään nyt antamaan commit-viesti uudelle commitille, joka syntyy, kun yhdistetään nuo kaksi vanhaa commitia.

Syötetään uusi viesti uudelle, kokoonpuristetulle komitukselleSyötetään uusi viesti uudelle, kokoonpuristetulle komitukselle

Tallennuksen ja tämän editori-ikkunan sulkemisen jälkeen näet, että luotiin uusi komitus, joka sisältää molempien vanhojen komitusten muutossarjat. Voila!

Virheen korjaaminen

Toinen käyttötapaus interaktiiviselle uudelleensovittamiselle on, kun löysit virheen jossakin aiemmassa komitossasi. Eikä sillä ole väliä, mitä tarkalleen ottaen mokasit: voit olla unohtanut lisätä tietyn muutoksen, sinun olisi pitänyt poistaa tiedosto tai yksinkertaisesti lisätä kirjoitusvirhe…

Luonnollinen taipumus tällaisessa tilanteessa on yksinkertaisesti luoda uusi komitus, joka korjaa virheen. Mutta toisaalta tämä sotkee commit-historiamme: alkuperäisen commitin tekeminen ja sitten ”laastari”-commitin lisääminen vain virheiden korjaamiseksi… se on sotkuinen tapa työskennellä. Sitoumushistoriastasi tulee pian vaikeasti hahmotettava, koska se on täynnä näitä pieniä ”pikakorjauskommitointeja”!

Tässä kohtaa ”fixup”, yksi interaktiivisen rebasen mukana tulevista työkaluista, on erittäin kätevä. Fixup ottaa tämän ”pikakorjaus”-kommituksen, soveltaa sen muutoksia alkuperäiseen komitukseen (ja korjaa siten sen) ja hankkiutuu sitten eroon laastarikomituksesta:

Kuinka "fixup" toimiiKuinka ”fixup” toimii

Kun olemme valmiit, näyttää siltä, kuin alkuperäisessä komituksessamme ei olisi koskaan ollutkaan ongelmaa! Käydään siis tämä läpi käytännön esimerkin avulla.

Ensimmäinen vaihe on tehdä kaikki tarvittava ongelman korjaamiseksi: tämä voi tarkoittaa uuden tiedoston lisäämistä, muutosten tekemistä olemassa oleviin tiedostoihin, vanhentuneiden tiedostojen poistamista… sinun on ”vain” tuotettava muutokset, jotka korjaavat virheen.

Seuraava askel on näiden muutosten toimittaminen arkistoon – mutta pienellä lisäyksellä: kun teemme toimituksen, käytämme --fixup-lippua ja kerromme Gitille virheellisen toimituksemme toimituksen hashin:

$ git add corrections.txt$ git commit --fixup 2b504bee

Kun nyt vilkaiset toimitushistoriaa, huomaat, että on luotu melko tavalliselta näyttävä komitus – luultavasti se ei ole sellaista taikuutta ja ilotulitusta, jota olisit odottanut. Mutta jos katsot tarkemmin, huomaat, että jotain on tekeillä: uuden commitin eteen on automaattisesti lisätty ”fixup !” ja huonon commitimme commit-aihe.

Alkuperäinen commit ja fix-commitAlkuperäinen commit ja fix-commit

Kolmas vaihe on nyt vuorovaikutteisen rebase-istunnon käynnistäminen. Jälleen valitsemme lähtökohdaksi huonon commitimme vanhemman…

$ git rebase -i 0023cddd --autosquash

… ja salaisen kastikkeen toisena osana käytämme --autosquash-lippua. Tämä vaihtoehto varmistaa, että meidän ei tarvitse tehdä mitään editori-ikkunassa, joka on nyt auki. Katso tilannetta tarkkaan:

Korjauskomituksemme on merkitty "fixup" ja lajiteltu oikeaan paikkaanKorjauskomituksemme on merkitty ”fixup” ja lajiteltu oikeaan paikkaan

Havaitset, että Git teki automaattisesti kaksi asiaa puolestamme:

  1. Se merkitsi laastarikomituksemme korjauskomitukseksi.”
  2. Se järjesteli rivit uudelleen niin, että band-aid commitimme näkyy suoraan huonon commitimme alapuolella. Tämä johtuu siitä, että fixup toimii täsmälleen kuten squash siinä mielessä, että se yhdistyy yläpuolella olevaan riviin.

Muilla sanoilla: meille ei jää muuta tehtäväksi kuin tallentaa ja sulkea editori-ikkuna.

Katsotaanpa vielä kerran commit-historiaa:

Hyvinvoiva lopputulos!Hyvinvoiva lopputulos!

Alunperin huono komituksemme sisältää nyt muutokset band-aid-komituksestamme. Mutta kaiken lisäksi ruma band-aid-toimitus on kadonnut commit-historiasta! Kaikki on kaunista ja siistiä, aivan kuin ongelmaa ei olisi koskaan ollutkaan!

Discover the power of interactive rebase

Vuorovaikutteiselle rebaselle on paljon käyttötapauksia – ja useimmat niistä ovat ”virheiden korjaamisen” osastolla. Jos haluat yleiskatsauksen muihin hyödyllisiin asioihin, joita voit tehdä, suosittelen ilmaista ”First Aid Kit for Git” -julkaisua: se on kokoelma lyhyitä videoita (2-3 min per jakso), joiden avulla opit korjaamaan virheitä interaktiivisen rebasen ja muiden Git-työkalujen avulla.

Toimittajan huomautus: Jouduin käyttämään interaktiivista rebasea, kun tarkistin juuri tätä postausta! Yksi kommitoinneistani sisälsi kuvan, joka oli yli 1MB, mikä on GitLabin verkkosivuprojektin sääntöjen vastaista. Jouduin palaamaan takaisin ja korjaamaan kyseisen toimituksen sisältääkseni sen sijaan oikean kokoisen kuvan. Kiitos oppitunnista, universumi! 😁

Lisää Git-vinkkejä ja niksejä

  • 15 Git-vinkkiä työnkulun parantamiseen
  • Miten Gitin osittaisen kloonauksen avulla voit hakea vain tarvitsemasi suuren tiedoston
  • Gitissä tapahtuu! 6 yleistä Git-virhettä ja miten ne korjataan

Tietoa vierailevasta kirjoittajasta

Tobias Günther on Towerin toimitusjohtaja, suositun Git-työpöytäasiakkaan, joka auttaa yli 100 000 kehittäjää ympäri maailmaa olemaan tuottavampia Gitin avulla.

Kannen kuva: David Taljat on Pexels

Vastaa

Sähköpostiosoitettasi ei julkaista.