7.7 Orodja Git - Demistifikacija ponastavitve

HEAD je kazalec na trenutno vejno referenco, ki pa je sama po sebi kazalec na zadnjo potrditev, narejeno na tej veji. To pomeni, da bo HEAD nadrejeni naslednje ustvarjene potrditve. Na splošno je najpreprosteje razmišljati o HEAD-u kot o posnetku vaše zadnje potrditve na tej veji.

Dejansko je precej enostavno videti, kako je ta posnetek videti. Tukaj je primer pridobivanja dejanskega seznama direktorijev in kontrolnih vsot SHA-1 za vsako datoteko v posnetku HEAD:

Gitova ukaza cat-file in ls-tree sta ukaza »napeljave«, ki se uporabljata za stvari nižje ravni in nista resnično uporabljena v vsakodnevnem delu, vendar nam pa pomagata videti, kaj se dogaja tukaj.

Indeks je vaša naslednja predlagana potrditev. To zasnovo smo označevali tudi kot Gitovo »področje priprave«, saj si ga Git ogleda, ko zaženete ukaz git commit.

Git napolni ta indeks s seznamom vsebine datotek, ki so bile nazadnje izvlečene v vaš delovni direktorij, in kako so bile videti, ko so bile prvotno izvlečene. Nato nekatere od teh datotek nadomestite z novimi različicami in git commit to pretvori v drevo za novo potrditev.

Tukaj ponovno uporabljamo git ls-files, ki je bolj ukaz v zakulisju in vam prikaže, kako je trenutno videti vaš indeks.

Indeks tehnično gledano ni drevesna struktura — dejansko je implementiran kot sploščen manifest — vendar za naše namene je dovolj blizu.

Nazadnje imate vaš delovni direktorij (ki se pogosto imenuje tudi »delovno drevo«). Drugi dve drevesi shranjujeta svojo vsebino na učinkovit, vendar nepraktičen način v direktoriju .git. Delovni direktorij jih razpakira v dejanske datoteke, kar vam omogoča lažje urejanje. Delovni direktorij si lahko predstavljate kot peskovnik, kjer lahko preizkusite spremembe, preden jih potrdite v področje priprave (indeks) in nato v zgodovino.

Prva stvar, ki jo reset naredi, je premik tistega, na kar kaže HEAD. To ni enako spreminjanju samega HEAD (to naredi ukaz checkout); reset premakne vejo, na katero kaže HEAD. To pomeni, da če je HEAD nastavljen na vejo master (torej se trenutno nahajate na veji master), bo izvajanje ukaza git reset 9e5e6a4 najprej spremenilo master, da kaže na 9e5e6a4.

Ne glede na to, katero obliko reset z določeno potrditvijo uporabite, je to prva stvar, ki jo bo vedno poskusil narediti. Z uporabo reset --soft se bo postopek tam preprosto ustavil.

Sedaj si vzemite trenutek in si oglejte ta diagram ter ugotovite, kaj se je zgodilo: v bistvu se je preklical zadnji ukaz git commit. Ko zaženete git commit, Git ustvari novo potrditev in nanjo premakne vejo, na katero kaže HEAD. Ko se z ukazom reset vrnete na HEAD~ (na nadrejeno od HEAD), premaknete vejo nazaj na prejšnje mesto, pri tem pa ne spremenite indeksa ali delovnega direktorija. Sedaj lahko posodobite indeks in znova zaženete git commit, da dosežete to, kar bi naredil git commit --amend (glejte Spreminjanje zadnje potrditve).

Opazite lahko, da boste z zagonom ukaza git status sedaj videli v zeleni barvi razliko med indeksom in tem, kam kaže novi HEAD.

Naslednja stvar, ki jo bo reset naredil, je posodobitev indeksa z vsebino posnetka, na katerega sedaj kaže HEAD.

Če določite možnost --mixed, se bo postopek ukaza reset ustavil na tem koraku. To je tudi privzeta možnost, zato če ne navedete nobene možnosti (v tem primeru le git reset HEAD~), se bo ukaz končal tukaj.

Sedaj si vzemite še eno sekundo, da si ogledate ta diagram in ugotovite, kaj se je zgodilo: še vedno ste preklicali zadnji ukaz commit, vendar ste tudi premaknili vse spremembe iz indeksa v delovni direktorij. Vrnili ste se na stanje pred zagonom ukazov git add in git commit.

Tretja stvar, ki jo bo reset naredil, je, da bo delovni direktorij videti tako kot indeks. Če uporabite možnost --hard, se bo nadaljeval na tej stopnji.

Razmislimo o tem, kaj se je pravkar zgodilo. Preklicali ste zadnjo potrditev, ukaza git add in git commit ter vso delo, ki ste ga opravili v svojem delovnem direktoriju.

Pomembno je opozoriti, da je ta zastavica (--hard) edini način, da je ukaz reset nevaren, in eden izmed zelo redkih primerov, ko Git dejansko uniči podatke. Katerakoli drugačna uporaba ukaza reset se lahko precej enostavno razveljavi, ne pa možnost --hard, saj silovito prepiše datoteke v delovnem direktoriju. V tem posebnem primeru imamo še vedno različico v3 naše datoteke v potrditvi v naši bazi podatkov Git in jo lahko dobimo nazaj s pogledom v naš reflog, vendar bi jo Git še vedno prepisal, če je ne bi potrdili, in postala bi nepopravljivo izgubljena.

Ukaz reset prepisuje ta tri drevesa v določenem vrstnem redu in se ustavi, ko mu to sporočite:

Izvedba git checkout [branch] je precej podobna izvedbi git reset --hard [branch], saj posodobi vsa tri drevesa tako, da so videti kot [branch], vendar obstajata dve pomembni razliki.

Prvič, glede na reset --hard je checkout varnejši glede delovnega direktorija; preveri, da ne briše datotek, ki so že spremenjene. Pravzaprav je malce pametnejši od tega — poskuša narediti trivialno združevanje v delovnem direktoriju, zato bodo vse datoteke, ki jih niste spremenili, posodobljene. reset --hard pa preprosto nadomesti vse preko celega nabora brez preverjanja.

Druga pomembna razlika je, kako checkout posodobi HEAD. Kjer reset premakne vejo, na katero kaže HEAD, checkout premakne sam HEAD, da kaže na drugo vejo.

Na primer, recimo, da imamo veji master in develop, ki kažeta na različni potrditvi, in smo trenutno na veji develop (tako da kaže HEAD nanjo). Če izvedemo git reset master, se bo develop sama premaknila na isto potrditev kot master. Če pa izvedemo git checkout master, se develop ne premakne, premakne se sam HEAD. HEAD bo sedaj kazal na master.

V obeh primerih premikamo HEAD, da kaže na potrditev A, vendar je način, kako to storimo, zelo drugačen. reset premakne vejo, na katero kaže HEAD, checkout pa premakne sam HEAD.

Drugi način izvedbe ukaza checkout je s potjo do datoteke, kar, tako kot pri reset, ne premakne HEAD-a. Gre za isto kot git reset [branch] file, saj posodobi indeks z datoteko v tej potrditvi in prepiše datoteko v delovnem direktoriju. Gre za popolnoma enako reč, kot je git reset --hard [branch] file (če bi lahko to izvedli z reset) — ni varno za delovni direktorij in ne premakne HEAD-a.

Podobno kot pri git reset in git add, tudi checkout sprejme možnost --patch, s katero lahko izberete, katere vsebine datoteke želite selektivno povrniti po koščkih.