Aloittelijan opas interaktiiviseen uudelleenkäsittelyyn

Tämän vuoden alussa tein interaktiivisen uudelleenpohjan ensimmäistä kertaa ja olin vaikuttunut siitä, mitä sillä voi tehdä. Minusta se oli myös aluksi hieman monimutkainen. Toivottavasti tämä opas auttaa poistamaan jonkin verran epävarmuutta sen ympäriltä.

Mikäli se on niin voimakas ja voit periaatteessa kirjoittaa historiaa uudelleen, pieni varoitus ennen kuin aloitamme: Gitistä ja siitä, onko rebasing hyvä idea vai ei, on monia koulukuntia. Tässä postauksessa ei sukelleta näihin keskusteluihin, vaan tarkoituksena on pelkästään käydä läpi interaktiivisen rebasingin käytön perusteet.

TL;DR

• Interaktiivista rebasingia voidaan käyttää kommittien muuttamiseen monin tavoin, kuten muokkaamiseen, poistamiseen ja squashaamiseen.
• Käskyäksesi Gitille, mistä interaktiivinen uudelleenkohdistus aloitetaan, käytä sen commitin SHA-1:tä tai indeksiä, joka edeltää välittömästi sitä commitia, jota haluat muuttaa.
• Vuorovaikutteisen uudelleenkohdistuksen aikana, kun Git pysähtyy muokattavaksi merkityn commitin kohdalla, työnkulku ei poikkea normaalista commit-prosessista – vaiheistat tiedostoja ja sitten commitoit ne. Ainoa ero on, että käytät komentoa git commit --amend komennon git commit sijaan.
• Interaktiivinen uudelleenkohdentaminen luo uusia SHA-1:iä, joten interaktiivista uudelleenkohdentamista kannattaa käyttää kommitointeihin, joita et ole työntänyt etähaaraan.

Ongelma

Tässä esimerkissämme käymme läpi tilanteen, jossa olemme työskennelleet feature-haarassa ja meillä on muutama kommitointi, joita haluaisimme muuttaa tai poistaa. Git-lokimme näyttää seuraavalta:

Yllä olevasta git-lokista löytyvät kaksi kommitiota, jotka haluamme muuttaa:
4a4d705 – Tässä kommitissa teimme vahingossa yhdistämiskonfliktin
6c01350 – Tässä kommitissa poistimme yhdistämiskonfliktin

Mitä haluaisimme tehdä, on palata ajassa taaksepäin kohtaan 4a4d705, poistaa yhdistämiskonflikti kommitissa ja poistaa sitten 6c01350, koska yhdistämiskonflikti on ratkaistu emmekä enää tarvitse tätä komitiota. Tämä on parannus commit-historiaamme kahdesta syystä:

1. Meillä ei tule olemaan rikkinäisiä kommitteja (sulautumisristiriitoja)
2. Meillä tulee olemaan vain mielekkäitä kommitteja, ei kommitteja, jotka liittyvät pelkästään ohi menneen sulautumisristiriidan korjaamiseen

Ratkaisu

Tilanne sopii hyvin vuorovaikutteiseen uudelleensovittamiseen. Scott Chacon kuvaa kirjassaan Pro Git interaktiivista uudelleenkohdentamista seuraavasti: ”Joskus korjattua asiaa … ei voida muuttaa sen korjaamaan, ei aivan täydelliseen toimitukseen, koska kyseinen toimitus on hautautunut syvälle patch-sarjaan. Juuri sitä varten on interaktiivinen rebase: käytä sitä runsaan , jälkeen järjestelemällä ja muokkaamalla kommitteja uudelleen ja litistämällä useita kommitteja yhdeksi.”

Mitä kommitteja haluamme muuttaa?

Aloittaaksemme interaktiivisen rebasen, meidän on kerrottava Gitille, mitä kommitteja haluamme muuttaa. Teemme tämän viittaamalla commitiin, joka on välittömästi ennen varhaisinta commitia, jota haluamme muokata. Tai yksinkertaisesti sanottuna viittaamme Scott Chaconin mukaan ”viimeiseen commitiin, jonka haluamme säilyttää sellaisenaan”.

Katsotaanpa esimerkkiä, jotta ymmärrämme sen paremmin. On kaksi tapaa viitata tähän commitiin:
By SHA-1 – Viimeisimmän commitin, jonka haluamme säilyttää sellaisenaan, SHA-1 on 528f82e, joten voimme siirtää sen interaktiiviseen rebase-komentoomme.
By Index – Viimeisellä sitoumuksella, jonka haluamme säilyttää sellaisenaan, on indeksipaikka 3 (Git käyttää nollapohjaista indeksointia), joten voimme välittää HEAD~3 interaktiiviseen rebase-komentoomme.

Huomautus – Jos sinulla on vain muutama sitoumus, jonka interaktiivista rebasea haluat tehdä, indeksin käyttäminen on luultavasti helpompaa useimmille. Jos sinulla on kuitenkin monia kommitteja, SHA-1:n käyttäminen on luultavasti helpompaa, jotta sinun ei tarvitse laskea koko git-lokia.

Aloita interaktiivinen uudelleenkäsittely

Aloitamme esimerkkimme perusteella joko:

$ git rebase -i 528f82e

Or

$ git rebase -i HEAD~3

Jolloin avautuu tämä ikkuna Vimissä:

Huomaa, että kommitit ovat päinvastaisessa järjestyksessä kuin git-lokissa. Git-logissa viimeisin komitus on päällimmäisenä. Tässä näkymässä viimeisin sitoumus on alhaalla. Huomaa myös, että alla olevissa kommenteissa on hyödyllinen luettelo kelvollisista komennoista, joita voimme käyttää kussakin kommitissa.

Jos et tunne Vimiä, klikkaa jokaista muokattavaa sanaa pick ja paina sitten <i>-näppäintä (insert-tilaan). Kun olet valmis kirjoittamaan, paina <esc>-näppäintä poistuaksesi insert-tilasta.

Esimerkissämme olemme muuttaneet komennon edit komennoksi komennolle, jota haluamme muuttaa, ja komennon drop komennoksi komennolle, jonka haluamme poistaa. Sitten suoritamme :wq tallentaaksemme ja lopetamme Vim-ikkunan.

Muuttaa commit

Takaisin terminaalissa näemme tämän viestin:

Tässä on järkeä, että olemme pysähtyneet kohtaan 4a4d705. Tämä on vanhin sitoumus sitoumusten sarjassa, jota haluamme muuttaa. Aloitamme tästä sitoumuksesta ja käymme läpi jokaisen sitoumuksen aina viimeisimpään asti.

Muistutuksena: 4a4d705 oli se sitoumus, jossa oli yhdistämisristiriita, jonka me vahingossa teimme. Kun avaamme editorin, näemme yhdistämisristiriidan siellä:

Korjaamme siis tiedostossa olevan yhdistämisristiriidan, mutta mitä teemme nyt? Kun olet epävarma, git status:

Cool! Tästä on oikeasti apua. Näemme, että muokkaamme parhaillaan 4a4d705, ja näemme kaksi seuraavaa toimitusta, joihin toimitaan tämän jälkeen.

Loppuosa viestistä selittää meille tuttua työnkulkua. Git kertoo meille, että jos haluamme muuttaa toimitusta, suoritamme git commit --amend. Tämä toimii pohjimmiltaan kuin tyypillinen git commit, jota käytämme normaalissa työnkulussa. Tämän viestin alareunassa näemme, että tiedostoamme on muutettu heijastaen muutoksia, jotka juuri teimme yhdistämisristiriidan poistamiseksi. Meidän on tehtävä tiedostolle vaiheistus, ennen kuin toimitamme sen. Tämä ei eroa normaalista työnkulusta.

Tehdään vain git add tempChanger.js muokatun tiedoston vaiheistamiseksi ja sitten git commit --amend vaiheistetun tiedoston sitouttamiseksi! Tämä avaa nyt jälleen Vim-ikkunan, jossa on commit-viesti:

Voidaan joko muokata commit-viestiä tai jättää se sellaisenaan. Valitaan, että pidämme commit-viestin ennallaan ja kirjoitamme :wq tallentaaksemme ja poistuaksemme ikkunasta.

Olemme nyt muokanneet vanhaa commit-viestiämme. Mitä nyt tapahtuu? Ajetaan git status:

Jatketaan vuorovaikutteista uudelleenkäsittelyä

Meillä ei ole enää muuta muutettavaa commitissa, joten jatketaan!

Ajetaan git rebase --continue ja näemme seuraavan viestin:

Vai niin, olemme valmiita? Mutta entä nuo kaksi muuta kommitointia? No, seuraava toimeksianto, jonka mukaan toimitaan, oli 6c01350. Tämän commitin merkitsimme poistettavaksi (drop), kun aloitimme interaktiivisen uudelleentallennuksen. Git poisti sen automaattisesti ja siirtyi seuraavaan commitiin, 41aa9d2. Tätä ei koskaan muutettu alkuperäisessä interaktiivisessa uudelleenkäyttöönotossa. Sen oletuskomento oli pick, mikä tarkoittaa, että komitusta käytetään. Git sovelsi tuota komentoa ja koska se oli viimeinen komento, interaktiivinen uudelleenkäyttö päättyi.

Huomaa, että jos meillä olisi ollut lisää muokattavia komentoja, olisimme yksinkertaisesti siirtyneet seuraavaan komentoon ja aloittaneet sen muuttamisen aivan kuten edellä. Sykli jatkuu, kunnes kommitteja ei ole enää jäljellä.

Hylkäyspainike

On syytä huomata, että jos jossain vaiheessa interaktiivista uudelleentarkasteluamme mokaamme asioita emmekä tiedä, miten korjata niitä, voimme aina keskeyttää. Voimme missä tahansa vaiheessa ajaa git rebase --abort terminaalissa, jolloin interaktiivinen uudelleenkäyttö keskeytetään ilman, että muutoksia tallennetaan. Tällöin meidän pitäisi aloittaa interaktiivinen rebase uudelleen.

Interaktiivisen rebasen jälkeen

Git-logimme näyttää nyt seuraavalta:

Huomaa, että muutama asia on muuttunut siitä, mitä olimme ennen interaktiivisen rebasen aloittamista:

• Meillä ei ole enää komitusta 6c01350, jossa on komitointiviestiä ”Poista sulauttamiskonflikti”. Tämä on sitoumus, jonka poistimme interaktiivisessa uudelleenkäyttöönotossa.
• Muokkaamallamme sitoumuksella 4a4d705 on eri SHA-1, 2b7443d.
• Myös viimeisimmällä sitoumuksellamme alkuperäisestä git-lokistamme, 41aa9d2, on uusi SHA-1, 2b95e92. Tätä komitusta ei muutettu, vaan sitä yksinkertaisesti sovellettiin sitä edeltävään komitukseen 2b7443d.

Vuorovaikutteisen uudelleensovittamisen sivuvaikutukset

Kahdessa viimeisimmässä komituksessamme git-lokissamme Git näkee ne täysin uusina komituksina, koska niillä on uudet SHA-1:t. Tämä pätee jopa viimeisimpään toimitukseemme 2b95e92, jossa toimitusviesti tai tiedostot eivät muuttuneet lainkaan. Tämä tuo esiin tärkeän seikan vuorovaikutteisen uudelleenasennuksen suhteen: Jos muokkaat komitusta, kyseisellä komituksella ja kaikilla seuraavilla komituksilla on uudet SHA-1:t.

Tämä ei vaikuta mihinkään, jos muokkaamiasi komituksia ei ole siirretty etähaaraan. Jos kuitenkin itse asiassa suorittaisit vuorovaikutteisen uudelleentallennuksen kommitteihin, jotka oli jo työnnetty etähaaraan, ja sitten työnnät haarasi uudelleen, näkisit:

Teknisesti voisit kiertää tämän käyttämällä git push --force, mutta se on hyvin vaarallista. Jos etähaarassa on muiden tekemiä kommitteja, mutta paikallisessa haarassasi ei vielä ole näitä kommitteja, poistat käytännössä heidän kommitoitumisensa.

Toinen ratkaisu on käyttää git push --force-with-lease, joka muuttaa vain sinun kommitoitumisesi, mutta ei muiden tekemiä kommitteja, mutta tämäkin voi olla ongelmallista. Jos esimerkiksi toisella kehittäjällä on jo nuo kommitit, joille annettiin uudet SHA-1:t heidän paikallisessa haarassaan, kun he vetävät etähaaran, heillä on sulautumisristiriitoja kaikkien näiden kommittien kanssa.

Milloin --force-with-lease:ää kannattaa käyttää, ei kuulu tämän blogikirjoituksen aihepiiriin, mutta olisi parasta neuvotella tiimisi muiden jäsenten kanssa, ennen kuin teet niin. Voit lukea lisää git push --force-with-lease:sta täältä.

Tästä osiosta tärkein opetus on se, että on paljon helpompaa ja turvallisempaa käyttää interaktiivista uudelleensovittamista kommitointeihin, joita ei ole vielä työnnetty etähaaraan.

Kirjoittanut Blake DeBoer. Julkaistu alun perin sivustolla Dev.to

Senior, Lead tai Principal developer in NYC? Stride palkkaa työntekijöitä! Haluatko nostaa teknisen tiimisi tasoa? Katso, miten me teemme sen! www.stridenyc.com