7.7 Git Tools - Reset ontrafeld

Een eenvoudiger manier om je reset en checkout voor te stellen is door je voor te stellen dat Git een gegevensbeheerder is van drie boomstructuren. Met “boom” bedoelen we hier eigenlijk “verzameling van bestanden”, en niet een bepaalde gegevensstructuur. (Er zijn een paar gevallen waarbij de index zich niet echt als een boomstructuur gedraagt, maar voor dit doeleinde is het eenvoudiger om het je als zodanig voor te stellen).

Git als systeem beheert en manipuleert deze boomstructuren bij de gewone operaties:

Het voornaamste doel van Git is om opeenvolgende snapshots te op te slaan van verbeteringen aan je project, door deze drie bomen te manipuleren.

Laten we dit proces eens visualiseren: stel je gaat een nieuwe directory in waarin een enkel bestand staat. We noemen dit v1 van het bestand, en we geven het in blauw weer. Nu roepen we git init aan, wat een Git repository aanmaakt met een HEAD referentie die verwijst naar een ongeboren branch (master bestaat nog niet).

Op dit moment heeft alleen de boom van de werk directory inhoud.

Nu willen we dit bestand committen, dus we gebruiken git add om de inhoud van de werk directory te pakken en dit in de index te kopiëren.

Dan roepen we git commit aan, wat de inhoud van de index pakt en deze bewaart als een permanente snapshot, een commit object aanmaakt die naar die snapshot wijst en dan master update die naar die commit wijst.

Als we nu git status aanroepen zien we geen wijzigingen, omdat alle drie bomen hetzelfde zijn.

Nu willen we dat bestand wijzigen en deze committen. We volgen hetzelfde proces; eerst wijzigen we het bestand in onze werk directory. Laten we deze v2 van het bestand noemen, en deze in het rood weergeven.

Als we nu git status aanroepen, zullen we het bestand in het rood zien als “Changes not staged for commit,” omdat deze versie van het bestand verschilt tussen de index en de werk directory. Nu gaan we git add aanroepen om het in onze index te stagen ("to stage": klaarzetten).

Als we op dit moment git status aanroepen zullen we het bestand in het groen zien onder “Changes to be committed” omdat de index en HEAD verschillen — dat wil zeggen, onze voorgestelde volgende commit verschilt nu van onze laatste commit. Tot slot roepen we git commit aan om de commit af te ronden.

Nu zal git status geen uitvoer laten zien, omdat alle drie bomen weer hetzelfde zijn.

Tussen branches overschakelen of klonen volgen een vergelijkbaar proces. Als je een branch uitcheckt, wijzigt dit HEAD door het te laten wijzen naar de nieuwe branch referentie, het vult je index met de snapshot van die commit, en kopieert dan de inhoud van de index naar je werk directory.

Het reset commando krijgt in dit licht meer betekenis.

Laten we, voor het doel van deze voorbeelden, stellen dat we file.txt weer gewijzigd hebben en het voor de derde keer gecommit. Nu ziet onze historie er dus als volgt uit:

Laten we nu een stap voor stap bespreken wat reset doet als je het aanroept. Het manipuleert deze drie bomen op een eenvoudige en voorspelbare manier. Het voert tot drie basale handelingen uit.

Dit dekt het gedrag van reset in zijn eenvoudige vorm, maar je kunt er ook een path bij opgeven waar het op moet acteren. Als je een path opgeeft, zal reset stap 1 overslaan, en de rest van de acties beperken tot een specifiek bestand of groep van bestanden. Dit is ergens wel logisch — HEAD is maar een verwijzing, en je kunt niet naar een deel van een commit wijzen en deels naar een andere. Maar de index en werk directory kunnen deels worden bijgewerkt, dus reset gaat verder met stappen 2 en 3.

Dus, laten we aannemen dat we git reset file.txt aanroepen. Deze vorm (omdat je niet een specifieke SHA-1 van een commit of branch meegeeft, en je hebt geen --soft of --hard meegegeven) is dit een verkorte vorm van git reset --mixed HEAD file.txt en dit zal:

Dus effectief wordt alleen file.txt van HEAD naar de index gekopiëerd.

Dit heeft het praktische effect van het bestand unstagen. Als we kijken naar het diagram voor dat commando en denken aan wat git add doet, zijn ze exact elkaars tegenpolen.

Dit is de reden waarom de uitvoer van het git status commando je aanraadt om dit aan te roepen om een bestand te unstagen. (Zie Een gestaged bestand unstagen voor meer hierover.)

We hadden net zo makkelijk Git niet laten aannemen dat we “pull de data van HEAD” bedoelen door een specifieke commit op te geven om die versie van het bestand te pullen. We hadden ook iets als git reset eb43bf file.txt kunnen aanroepen.

Feitelijk gebeurt hier hetzelfde als wanneer we de inhoud van het bestand naar v1 in de werk directory hadden teruggedraaid, git add ervoor hadden aangeroepen, en daarna het weer hadden teruggedraaid naar v3 (zonder daadwerkelijk al deze stappen te hebben gevolgd). Als we nu git commit aanroepen, zal het een wijziging vastleggen die het bestand naar v1 terugdraait, ook al hebben we het nooit echt weer in onze werk directory gehad.

Het is ook interessant om op te merken dat net als git add, het reset commando een --patch optie accepteert om inhoud in deelsgewijs te unstagen. Dus je kunt naar keuze inhoud unstagen of terugdraaien (revert).

Laten we nu kijken hoe we iets interessants kunnen doen met deze vers ontdekte krachten — commits samenpersen (squashen).

Stel dat je een reeks van commits met berichten als “oops.”, “WIP” en “dit bestand vergeten”. Je kunt reset gebruiken om deze snel en makkelijk in een enkele commit te samenpersen waardoor je ontzettend slim zult lijken. (Een commit samenpersen (squashing) laat je een andere manier zien om dit te doen, maar in dit voorbeeld is het makkelijker om reset te gebruiken.)

Stel dat je een project hebt waar de eerste commit een bestand heeft, de tweede commit een nieuw bestand toevoegde en het eerste wijzigde, en de derde commit het eerste bestand weer wijzigde. De tweede commit was een onderhanden werk en je wilt het samenpersen.

Je kun git reset --soft HEAD~2 uitvoeren om de HEAD branch terug naar een oudere commit te verplaatsen (de eerste commit wil je behouden):

En daarna eenvoudigweg git commit weer aanroepen:

Je kunt nu zien dat je bereikbare historie, de historie die je zou gaan pushen, nu eruit ziet alsof je een commit had met file-a.txt v1, dan een tweede die zowel file-a.txt naar v3 wijzigt en file-b.txt toevoegt. De commit met de v2 versie van het bestand is niet meer in de historie aanwezig.

Als laatste, je kunt je afvragen wat het verschil is tussen checkout en reset. Net als reset, bewerkt checkout de drie bomen, en het verschilt enigszins afhankelijk van of je het commando een bestandspath geeft of niet.

Hopelijk begrijp je nu het reset commando en voel je je er meer mee op je gemak, maar je zult waarschijnlijk nog een beetje in verwarring zijn in hoe het precies verschilt van checkout en zul je je waarschijnlijk ook niet alle regels van verschillende aanroepen herinneren.

Hier is een spiekbrief voor welke commando’s welke bomen beïnvloeden. In de “HEAD” kolom staat “REF” als dat commando de referentie (branch) waar HEAD naar wijst verplaatst, en “HEAD” als het HEAD zelf verplaatst. Let met name op de WD Safe? kolom - als daar NO in staat, bedenk je een tweede keer voordat je dat commando gebruikt.