7.7 Git Tools - Reset Ontmystifiseer (Reset Demystified)

'n Makliker manier om oor reset en checkout te dink, is deur die raamwerk van Git as 'n inhoudsbestuurder van drie verskillende bome. Deur “boom” (“tree”) hier, bedoel ons regtig “versameling van lêers”, nie spesifiek die datastruktuur nie. (Daar is 'n paar gevalle waar die indeks (index) nie presies soos 'n boom optree nie, maar vir ons doeleindes is dit makliker om vir eers so daaroor te dink.)

Git as 'n stelsel bestuur en manipuleer drie bome in sy normale werking:

Git se tipiese werkvloei is om momentopnames van jou projek in agtereenvolgens beter toestande op te neem deur hierdie drie bome te manipuleer.

Kom ons visualiseer hierdie proses: sê nou jy gaan na 'n nuwe gids met 'n enkele lêer daarin. Ons sal dit v1 van die lêer noem, en ons sal dit in blou aandui. Nou voer ons git init uit, wat 'n Git-bewaarplek sal skep met 'n HEAD-verwysing wat na die ongebore master tak wys.

Op hierdie punt het slegs die werkgidsboom enige inhoud.

Nou wil ons hierdie lêer vaslê, so ons gebruik git add om inhoud in die werkgids te neem en dit na die indeks te kopieer.

Dan voer ons git commit uit, wat die inhoud van die indeks neem en dit as 'n permanente momentopname stoor, 'n vasleggingsobjek skep wat na daardie momentopname wys, en master opdateer om na daardie vaslegging te wys.

As ons git status uitvoer, sal ons geen veranderings sien nie, want al drie bome is dieselfde.

Nou wil ons 'n verandering aan daardie lêer maak en dit vaslê. Ons sal deur dieselfde proses gaan; eers verander ons die lêer in ons werkgids. Kom ons noem dit v2 van die lêer, en dui dit in rooi aan.

As ons git status dadelik uitvoer, sal ons die lêer in rooi sien as “Changes not staged for commit”, omdat daardie inskrywing verskil tussen die indeks en die werkgids. Volgende voer ons git add daarop uit om dit in ons indeks voor te berei (stage).

Op hierdie punt, as ons git status uitvoer, sal ons die lêer in groen sien onder “Changes to be committed” omdat die indeks en HEAD verskil — dit wil sê, ons voorgestelde volgende vaslegging verskil nou van ons laaste vaslegging. Laastens voer ons git commit uit om die vaslegging te finaliseer.

Nou sal git status ons geen afvoer gee nie, want al drie bome is weer dieselfde.

Die omskakeling van takke of die kloning van 'n bewaarplek gaan deur 'n soortgelyke proses. Wanneer jy 'n tak uitcheck, verander dit HEAD om na die nuwe tak-verwysing (ref) te wys, vul jou indeks met die momentopname van daardie vaslegging, kopieer dan die inhoud van die indeks na jou werkgids.

Die reset opdrag maak meer sin wanneer dit in hierdie konteks beskou word.

Vir die doeleindes van hierdie voorbeelde, kom ons sê ons het file.txt weer gewysig en dit 'n derde keer vasgelê. So nou lyk ons geskiedenis so:

Kom ons stap nou presies deur wat reset doen wanneer jy dit aanroep. Dit manipuleer direk hierdie drie bome op 'n eenvoudige en voorspelbare manier. Dit doen tot drie basiese bewerkings.

Dit dek die gedrag van reset in sy basiese vorm, maar jy kan dit ook voorsien van 'n pad (path) om op op te tree. As jy 'n pad spesifiseer, sal reset stap 1 oorslaan, en die res van sy aksies beperk tot 'n spesifieke lêer of stel lêers. Dit maak eintlik 'n bietjie sin — HEAD is net 'n wyser, en jy kan nie na 'n deel van een vaslegging en 'n deel van 'n ander wys nie. Maar die indeks en werkgids kan gedeeltelik opgedateer word, so reset gaan voort met stappe 2 en 3.

So, neem aan ons voer git reset file.txt uit. Hierdie vorm (aangesien jy nie 'n vaslegging SHA-1 of tak gespesifiseer het nie, en jy nie --soft of --hard gespesifiseer het nie) is 'n kortskrif vir git reset --mixed HEAD file.txt, wat sal:

So dit kopieer in wese net file.txt van HEAD na die indeks.

Dit het die praktiese effek om die lêer onvoorbereid (unstaging) te maak. As ons na die diagram vir daardie opdrag kyk en dink oor wat git add doen, is hulle presies die teenoorgesteldes.

Dit is hoekom die afvoer van die git status opdrag voorstel dat jy dit uitvoer om 'n lêer onvoorbereid te maak (sien 'n Voorbereide lêer onttrek (Unstaging a Staged File) vir meer hieroor).

Ons kon net so maklik Git nie laat aanneem het ons bedoel “trek die data van HEAD af” deur 'n spesifieke vaslegging te spesifiseer om daardie lêerweergawe van af te trek (pull). Ons sou net iets soos git reset eb43bf file.txt uitvoer.

Dit doen effektief dieselfde ding asof ons die inhoud van die lêer teruggerol (reverted) het na v1 in die werkgids, git add daarop uitgevoer het, en dit dan weer teruggerol het na v3 (sonder om eintlik deur al daardie stappe te gaan). As ons nou git commit uitvoer, sal dit 'n verandering opneem wat daardie lêer terugrol na v1, al het ons dit nooit regtig weer in ons werkgids gehad nie.

Dit is ook interessant om op te let dat, net soos git add, sal die reset opdrag 'n --patch opsie aanvaar om inhoud onvoorbereid (unstage) te maak op 'n brok-vir-brok (hunk-by-hunk) basis. Jy kan dus selektief inhoud onvoorbereid maak of terugrol.

Kom ons kyk hoe om iets interessants met hierdie nuutgevonde krag te doen — die saampers (squashing) van vasleggings.

Sê jy het 'n reeks vasleggings met boodskappe soos “oops.”, “WIP” en “forgot this file”. Jy kan reset gebruik om hulle vinnig en maklik in 'n enkele vaslegging saam te pers wat jou baie slim laat lyk. Saampersing van Vasleggings (Squashing Commits) wys 'n ander manier om dit te doen, maar in hierdie voorbeeld is dit makliker om reset te gebruik.

Kom ons sê jy het 'n projek waar die eerste vaslegging een lêer het, die tweede vaslegging 'n nuwe lêer bygevoeg het en die eerste verander het, en die derde vaslegging die eerste lêer weer verander het. Die tweede vaslegging was werk in proses en jy wil dit saampers.

Jy kan git reset --soft HEAD~2 uitvoer om die HEAD-tak terug te skuif na 'n ouer vaslegging (die mees onlangse vaslegging wat jy wil behou):

En voer dan eenvoudig git commit weer uit:

Nou kan jy sien dat jou bereikbare geskiedenis, die geskiedenis wat jy sou opstuur (push), nou lyk asof jy een vaslegging gehad het met file-a.txt v1, dan 'n tweede wat beide file-a.txt verander het na v3 en file-b.txt bygevoeg het. Die vaslegging met die v2 weergawe van die lêer is nie meer in die geskiedenis nie.

Laastens mag jy wonder wat die verskil tussen checkout en reset is. Soos reset, manipuleer checkout die drie bome, en dit is 'n bietjie anders afhangende van of jy die opdrag 'n lêerpad (file path) gee of nie.

Hopelik verstaan jy nou en voel jy gemakliker met die reset opdrag, maar is waarskynlik steeds 'n bietjie verward oor hoe presies dit verskil van checkout en sou moontlik nie al die reëls van die verskillende oproepings (invocations) kon onthou nie.

Hier is 'n spiekbriefie vir watter opdragte watter bome beïnvloed. Die “HEAD” kolom lees “REF” as daardie opdrag die verwysing (tak) skuif waarna HEAD wys, en “HEAD” as dit HEAD self skuif. Gee veral aandag aan die 'WD Safe?' (Werkgids Veilig?) kolom — as dit sê NO, dink 'n oomblik na voordat jy daardie opdrag uitvoer.