7.1 Orodja Git - Izbira revizije

Očitno lahko navedete katerokoli posamezno potrditev po celotni 40-znakovni zgoščeni vrednosti SHA-1, vendar obstajajo načini, ki so bolj prijazni do uporabnikov. V tem razdelku so opisani različni načini, kako se lahko sklicujete na katerokoli potrditev.

Git je dovolj pameten, da ugotovi, katero potrditev mislite, če navedete prvih nekaj znakov zgoščene vrednosti SHA-1, če je ta delna zgoščena vrednost dolga vsaj štiri znake in je nedvoumna; to pomeni, da noben drug objekt v objektni bazi podatkov ne more imeti zgoščene vrednosti, ki se začne z enako predpono.

Na primer, da bi preučili določeno potrditev, kjer veste, da ste dodali določeno funkcionalnost, bi najprej pognali ukaz git log, da bi našli to potrditev:

V tem primeru recimo, da vas zanima potrditev, katere zgoščena vrednost se začne z 1c002dd…​. To potrditev lahko pregledate z uporabo katere koli od naslednjih različic git show (ob predpostavki, da so krajše različice nedvoumne):

Git lahko ugotovi kratko in edinstveno okrajšavo za vaše vrednosti SHA-1. Če podate --abbrev-commit ukazu git log, bo izhod uporabljal krajše vrednosti, vendar jih bo še vedno obdržal edinstvene; privzeto uporablja sedem znakov, vendar jih bo podaljšal, če je to potrebno, da ohrani edinstvenost SHA-1:

Na splošno je osem do deset znakov več kot dovolj, da so edinstveni v okviru projekta. Na primer, do februarja 2019 je imelo jedro Linux (ki je precej obsežen projekt) več kot 875.000 potrditev in skoraj sedem milijonov objektov v svoji objektni podatkovni bazi, pri čemer ni dveh objektov, ki bi imela enaki vrednosti SHA-1 v prvih 12 znakih.

Enostaven način za sklicevanje na določeno potrditev je, če je ta potrditev na vrhu veje; v tem primeru lahko v katerem koli ukazu Git, ki pričakuje sklicevanje na potrditev, uporabite ime veje. Na primer, če želite preučiti zadnji objekt potrditve v veji, sta naslednja ukaza enakovredna, če privzamemo, da se veja topic1 sklicuje na potrditev ca82a6d…​:

Če želite videti, na kateri specifični SHA-1 se nanaša veja, ali če želite videti, kaj kateri od teh primerov pomeni v smislu SHA-1, lahko uporabite Gitovo orodje napeljave imenovano rev-parse. Za več informacij o orodjih napeljave si oglejte poglavje Notranjost Gita; v osnovi obstaja orodje rev-parse za nižje nivojske operacije in ni zasnovano za vsakodnevno uporabo. Vendar pa je včasih lahko koristno, ko želite videti, kaj se v resnici dogaja. Tukaj lahko poženete rev-parse na svoji veji.

Ena od stvari, ki jih Git počne v ozadju med vašim delom, je ohranjanje »refloga« — dnevnika, kjer so shranjene informacije o tem, kje so bili vaš HEAD in reference vej v zadnjih nekaj mesecih.

Svoj reflog lahko vidite z uporabo git reflog:

Vsakič, ko se iz kakršnega koli razloga vaš vrh veje posodobi, Git shrani to informacijo v začasno zgodovino. Svoje podatke refloga lahko uporabite tudi za sklicevanje na starejše potrditve. Na primer, če želite videti peto predhodno vrednost HEAD vašega repozitorija, lahko uporabite referenco @{5}, ki jo vidite v izpisu refloga:

To sintakso lahko uporabite tudi za ogled, kje je bila veja pred določenim časom. Na primer, da bi videli, kje je bila vaša veja master včeraj, lahko vnesete:

To bi vam pokazalo, kje je bil vrh vaše veje master včeraj. Ta tehnika deluje samo za podatke, ki so še vedno v vašem reflogu, zato je ne morete uporabiti za iskanje potrditev, starejših od nekaj mesecev.

Če želite videti informacije refloga oblikovane kot izpis git log, lahko zaženete git log -g:

Pomembno je opozoriti, da so informacije o reflogu izključno lokalne — gre le za dnevnik tega, kar ste vi storili v vašem repozitoriju. Reference ne bodo enake na kopiji repozitorija nekoga drugega; tudi takoj po prvotnem kloniranju repozitorija boste imeli prazen reflog, saj se v vašem repozitoriju še ni zgodila nobena dejavnost. Če zaženete git show HEAD@{2.months.ago}, vam bo ujemajoča se potrditev prikazana samo, če ste projekt klonirali vsaj pred dvema mesecema — če ste ga klonirali še bolj nedavno, boste videli samo svojo prvo lokalno potrditev.

Drugi glavni način za določitev potrditve je prek njenega prednika. Če na koncu reference dodate ^ (karet), Git razume, da to pomeni nadrejeno te potrditve. Recimo, da pogledate zgodovino svojega projekta:

Nato lahko vidite prejšnjo potrditev z določitvijo HEAD^, kar pomeni »nadrejena od HEAD«:

Za ^ lahko navedete tudi številko, da identificirate, katero nadrejeno želite; na primer, d921970^2 pomeni »druga nadrejena d921970«. Ta sintaksa je uporabna le za potrditve združitev, ki imajo več kot eno nadrejeno — prva nadrejena od potrditve združitve je iz veje, na kateri ste bili, ko ste opravili združitev (pogosto master), medtem ko je druga nadrejena od potrditve združitve iz veje, ki je bila združena (recimo topic):

Druga glavna specifikacija prednikov je ~ (vijuga). Ta se prav tako nanaša na prvo nadrejeno, zato sta HEAD~ in HEAD^ enakovredna. Razlika postane očitna, ko navedete število. HEAD~2 pomeni »prvo nadrejeno od prve nadrejene« — skozi prve nadrejene gre tolikokrat, kolikor je navedeno število. Na primer, v prej omenjeni zgodovini bi bil HEAD~3:

To se lahko napiše tudi kot HEAD~~~, kar je ponovno prva nadrejena prve nadrejene od prve nadrejene.

Te sintakse lahko tudi kombinirate — dobite lahko drugo nadrejeno od prejšnje reference (ob predpostavki, da je šlo za potrditev združitve) z uporabo HEAD~3^2 itn.

Zdaj, ko lahko navedete posamezne potrditve, poglejmo, kako določiti obsege potrditev. To je še posebej koristno za upravljanje vej — če imate veliko vej, lahko z uporabo obsega potrditev odgovorite na vprašanja, kot so, »Kakšno delo je na tej veji, ki ga še nisem združil v svojo glavno vejo?«