7.13 Orodja Git - Zamenjava

Kot smo poudarili že prej, objekti v objektni podatkovni bazi Git niso spremenljivi, vendar Git ponuja zanimiv način pretvarjanja zamenjave objektov v svoji podatkovni bazi z drugimi objekti.

Ukaz replace vam omogoča določiti objekt v Gitu in povedati »vsakič, ko se sklicuješ na ta objekt, se pretvarjaj, da je drugačen objekt«. To je najpogostejše uporabno za zamenjavo ene potrditve v vaši zgodovini z drugo, brez da morate ponovno zgraditi celo zgodovino z recimo git filter-branch.

Na primer, predpostavimo, da imate veliko zgodovino kode in želite razdeliti svoj repozitorij v eno hitro zgodovino za nove razvijalce in eno veliko daljšo in večjo zgodovino za ljudi, ki jih zanima rudarjenje podatkov. Presadite lahko eno zgodovino v drugo z zamenjavo najnovejše potrditve v novi vrstici z najnovejšo potrditvijo na stari. To je dobro, ker pomeni, da vam ni treba dejansko prepisati vsake potrditve v novi zgodovini, kot bi običajno morali, da ju združite skupaj (ker nadrejenost vpliva na SHA-1).

Poskusimo to. Vzemimo obstoječi repozitorij, ga razdelimo v dva repozitorija, enega novejšega in enega zgodovinskega, ter nato bomo videli, kako lahko ponovno kombiniramo oba brez sprememb zadnjih vrednosti SHA-1 repozitorija preko replace.

Uporabili bomo enostaven repozitorij s petimi enostavnimi potrditvami:

To želimo prelomiti v dve liniji zgodovine. Ena linija gre iz prve potrditve v četrto potrditev — ta bo zgodovinska. Druga linija bo vsebovala samo potrditvi štiri in pet — to bo novejša zgodovina.

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

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

Dobro, sedaj je torej naša zgodovina objavljena. Sedaj je težji del skrajšanje naše novejše zgodovine navzdol, da je manjša. Narediti moramo prekrivanje, da lahko zamenjamo potrditev v eni enakovredni potrditvi v drugo, torej bomo skrajšali to na samo potrditvi štiri in pet (torej se potrditev štiri prekrije).

V tem primeru je uporabno ustvariti osnovno potrditev, da ima navodila, kako razširiti zgodovino, tako da drugi razvijalci vejo, kaj narediti, če pridejo do prve potrditve v skrajšani zgodovini in morajo imeti več. Torej, kar bomo naredili, je ustvarjanje začetnega objekta potrditve kot naše osnovne točke z navodili, nato pa bomo ponovno bazirali ostali potrditvi (štiri in pet) na vrhu le te.

Da to naredimo, moramo izbrati točko za razdelitev, ki bo za nas tretja potrditev, ki je 9c68fdc v jeziku SHA. Torej naša osnovna potrditev bo osnovana na tem drevesu. Ustvarimo lahko našo osnovno potrditev z uporabo ukaza commit-tree, ki samo vzame drevo in nam vrne popolnoma nov objekt potrditve SHA-1 brez nadrejene.

Torej sedaj, ko imamo osnovno potrditev, lahko naredimo ponovno baziranje 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čka ponovnega baziranja bo tretja potrditev (nadrejena prve potrditve, ki jo želimo obdržati, 9c68fdc):

Torej sedaj smo prepisali svojo novejšo zgodovino na vrhu ovržene osnovne potrditve, ki ima sedaj v njej navodila, kako rekonstruirati celotno zgodovino, če to želimo. Potisnemo lahko to novo zgodovino v nov projekt in sedaj, ko bodo ljudje klonirali ta repozitorij, bodo videli samo zadnji dve potrditvi in nato osnovno potrditev 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 prenesti:

Sedaj bi sodelavec moral imeti svoje zadnje potrditve v veji master in zgodovinske potrditve v veji project-history/master.

Da jih kombinirate, lahko enostavno pokličete git replace s potrditvijo, ki jo želite zamenjati, in nato dodate potrditev, ki jo želite z njo zamenjati. Torej želimo zamenjati četrto potrditev v veji master s četrto potrditvijo v veji project-history/master:

Če sedaj pogledate zgodovino veje master, je videti nekako takole:

Odlično, kajne? Brez da moramo spremeniti vse SHA-1 povratnega toka, smo lahko zamenjali eno potrditev v naši zgodovini s popolnoma drugo potrditvijo in vsa običajna orodja (bisect, blame itd) bodo delovala, kakor pričakujemo.

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

Zapomniti si je dobro, da je bila dejansko nadrejena 81a708d označba mesta potrditve (622e88e) in ne 9c68fdce, kakor je tu zabeleženo.

Druga zanimiva stvar je, da so ti podatki vključeni v naših referencah:

To pomeni, da je našo zamenjavo enostavno deliti z drugimi, ker lahko potisnemo to na svoj strežnik in drugi ljudje lahko to enostavno prenesejo. To ni toliko koristno v primeru presajanja zgodovine, kot smo šli skozi tu (ker bi vsak prenesel obe zgodovini tako ali tako, torej zakaj ju sploh ločevati?), vendar je lahko uporabno v drugih okoliščinah.