7.13 Orodja Git - Replace

Objekti v Git-u niso spremenljivi, vendar ponuja zanimiv način pretvarjanja zamenjave objektov v njegovi podatkovni bazi z drugimi objekti.

Ukaz replace vam omogoča določiti objekt v Git-u in povedati "vsakič ko to vidite, se pretvarjaj, da gre za drugo stvar". To je najpogostejše uporabno za zamenjavo enega pošiljanja v vaši zgodovini z drugim.

Na primer, predpostavimo, da imate veliko zgodovino kode in želite cepiti vaš repozitorij v eno hitro zgodovino za nove razvijalce in enega z veliko daljšo in večjo zgodovino za ljudi, ki jih zanima kopanje podatkov. Transplatirate lahko eno zgodovino v drugo z zamenjavo (replace) prejšnjih pošiljanj v novi vrstici z najnovejšim pošiljanjem na stari. To je lepo, ker pomeni, da vam ni potrebno dejansko prepisati vsakega pošiljanja v novi zgodovini, kot bi običajno morali, da ju združite skupaj (ker starševstvo vpliva na SHA-1).

Poskusimo to. Naredimo obstoječi repozitorij, ga cepimo v dva repozitorija, enega zadnjega in enega zgodovinskega in nato bomo videli, kako lahko ponovno kombiniramo oba brez sprememb zadnjih SHA-1 vrednosti repozitorija preko replace.

Uporabili bomo enostaven repozitorij s petimi enostavnimi pošiljanji:

Želimo to prelomiti v dve vrstici zgodovine. Ena vrstica gre iz prvega pošiljanja v četro pošiljanje - ta bo zgodovinski. Druga vrstica bosta samo pošiljanja 4 in 5.

Torej ustvarjanje zgodovinske zgodovine je enostavno, lahko samo damo vejo v zgodovino in nato potisnemo to vejo v glavno vejo novega oddaljenega repozitorija.

Sedaj lahko potisnemo novo vejo history v vejo master našega novega repozitorija:

Dobro, sedaj je naša zgodovina objavljena. Sedaj je težji del krajšanje naše zadnje zgodovine navzdol, da je manjša. Narediti moramo prekriavnje, da lahko zamenjamo pošiljanje v enem ekvivalentnem pošiljanju v drugem, torej bomo skrajšali to na samo pošiljanja 4 in 5 (torej se pošiljanje 4 prekrije).

V tem primeru je uporabno ustvariti osnovno pošiljanje, da ima navodila, kako razširiti zgodovino, da drugi razvijalci vejo, kaj narediti, če pridejo do prvega pošiljanja v prekriti zgodovini in potrebujejo več. Torej, kar bomo naredili je ustvarjanje začetnega objekta pošiljanja kot našo osnovno točko z navodili, nato naredili rebase ostalih pošiljanj (4 in 5) na vrhu le tega.

Da to naredimo, potrebujemo izbrati točko za cepitev, ki bo za nas tretje pošiljanje, ki je 9c68fdc v besedi SHA. Torej naše osnovno pošiljanje bo osnovano na tem drevesu. Lahko ustvarimo naše osnovno pošiljanje z uporabo ukaza commit-tree, ki samo vzame drevo in nam vrne popolnoma nov objekt pošiljanja SHA-1 brez starša.

Torej sedaj ko imamo osnovno pošiljanje, lahko naredimo t.i. rebase na naši preostali zgodovini na vrhu tega, z git rebase --onto. Argument --onto bo SHA-1, ki smo ga ravno dobili iz commit-tree in točke rebase-a bo tretje pošiljanje (starš prvega pošiljanja, ki ga želimo obdržati 9c68fdc):

Torej sedaj smo prepisali našo zadnjo zgodovino na vrhu ovrženeega osnovnega pošiljanja, ki ima sedaj navodila v njem, kako rekonstruirati celotno zgodovino, če to želimo. Lahko pošljemo to novo zgodovino v nov projekt in sedaj, ko ljudje klonirajo ta repozitorij, bodo videli samo zadnji dve pošiljanji in nato osnovno pošiljanje z navodili.

Sedaj preklopimo vloge nekomu, ki prvič klonira projekt in želi celotno zgodovino. Da dobimo podatke zgodovine po kloniranju tega skrajšanega repozitorija, bi nekdo moral dodati drugo daljavo za zgodovinski repozitorij in jo ujeti:

Sedaj bi sodelavec moral imeti svoja zadnja pošiljanja v veji master in zgodovinsko pošiljanje v veji project-history/master.

Da jih kombiniramo, lahko enostavno pokličete git replace s pošiljanjem, ki ga želite zamenjati in nato poslati, kar želite z njim zamenjati. Torej želimo zamenjati četrto pošiljanje v veji master s četrtim pošiljanjem v veji project-history/master:

Sedaj, če pogledate zgodovino veje master, izgleda nekako takole:

Kul, kajne? Brez, da moramo spremeniti vse SHA-1 zgornjega toka, smo lahko zamenjali eno pošiljanje v naši zgodovini s popolnoma drugim pošiljanjem in vsa običajna orodja (bisect, blame itd) bodo delovala kakor pričakujemo.

Zanimivo še vedno kaže 81a708d kot SHA-1, čeprav dejansko uporablja c6e1e95, podatke pošiljanja, s katerimi smo jih zamenjali. Tudi če poženete ukaz, kot je cat-file, vam bo pokazal zamenjane podatke:

Zapomniti si je dobro, da je bil dejanski starš 81a708d ograda pošiljanja (622e88e) in ne 9c68fdce kakor je tu zabeleženo.

Druga zanimiva stvar je, da so ti podatki obdržani v naši referenci:

To pomeni, da je enostavno deliti našo zamenjavo z drugimi, ker lahko potisnemo to na naš strežnik in drugi ljudje lahko to enostavno prenesejo. To ni v pomoč v zgodovini scenarija presadka, ko smo šli skozi tu (ker bi vsak prenesel obe zgodovini tako ali tako, torej zakaj ju ločiti?), vendar je lahko uporabno v drugih okoliščinah.