Herstel & de reflog

Git raakt zelden iets kwijt. Het lastige is het terugvinden.

Reflog

Elke verplaatsing van HEAD — en van elke branch — met wat hem veroorzaakte: checkout, reset, rebase, amend, een geforceerde fetch. Vanaf elke oude regel kun je hem uitchecken, eruit branchen of er hard naartoe resetten.

Dit is de knop "ik heb net de verkeerde branch gereset".

WIP-momentopnamen

Niet-gecommit werk is het enige dat de reflog niet kan redden, dus maakt Gitcito er momentopnamen van: de hele werkboom — gewijzigde, gestagede en niet-getrackte bestanden — gecommit via een wegwerp-index en vastgezet onder refs/gitcito/wip. Je echte index en je stashlijst blijven allebei onaangeroerd.

Drie dingen maken er een:

De bewaking is degene die ertoe doet: het moment waarop werk meestal voorgoed verloren gaat is de seconde na een verwerpen dat je niet bedoelde. Met de bewaking aan is die toestand een momentopname — open de lijst, klik op herstellen, haal weer adem.

Selecteer een momentopname om de vastgelegde bestanden te zien, de wijziging van elk bestand te bekijken, en een enkel bestand of de hele boom te herstellen. Herstellen kopieert bestanden uit de momentopname over de huidige kopieën heen — er wordt eerst een bewakingsmomentopname gemaakt, dus een herstel is zelf ook ongedaan te maken.

Grenzen die je moet kennen. Een timer- of bewakingstik die niets nieuws vindt, legt niets vast. Herstellen overschrijft bestanden en maakt ze opnieuw aan, maar verwijdert nooit een bestand dat je na de momentopname hebt aangemaakt. Genegeerde bestanden worden niet vastgelegd. Momentopnamen zijn lokale verborgen refs: nooit gepusht, veilig voor git gc, de nieuwste 50 blijven bewaard.

Begeleide bisect

Markeer commits als goed en slecht, kijk hoe het bereik smaller wordt, en land op de eerste slechte commit. Gitcito houdt bij hoeveel stappen er nog over zijn, zodat je weet of je twee vragen van het antwoord af zit of tien.

Laat een commando beslissen

Zodra het bereik is uitgezet, geeft Laat een commando beslissen de hele zoektocht over aan git bisect run. Git checkt elke kandidaat uit, draait jouw commando en leest de exitcode:

Een testsuite spreekt die taal al, en daarom is npm test meestal het hele antwoord. Gitcito biedt de eigen scripts van dit project aan om met één klik in te vullen, streamt de uitvoer terwijl het draait, en landt op de eerste slechte commit zonder dat jij ook maar één vraag beantwoordt.

Waar je op moet letten. Het commando draait op elke commit die git test, dus een commando dat deployt, publiceert of buiten de repository schrijft doet dat meerdere keren. Houd het bij iets dat alleen leest en rapporteert. Stop beëindigt de run en laat de sessie open, zodat je met de hand verder kunt markeren; Afbreken beëindigt de bisect volledig.

Een commando dat om een ongerelateerde reden faalt — een ontbrekende dependency op dat punt in de geschiedenis, bijvoorbeeld — markeert een goede commit als slecht en stuurt de zoektocht de verkeerde kant op. Met 125 afsluiten vanuit een wrapper-script is de uitweg die git daarvoor biedt.

Een achtergebleven lock-bestand

Git legt een .lock-bestand naast wat het gaat schrijven en haalt het weg zodra de schrijfactie klaar is. Een proces dat sterft terwijl het er een vasthoudt — een gecrashte editor, een terminal die tijdens git commit werd gesloten, een fetch die werd afgeschoten tijdens het opruimen van remote refs — laat de lock achter, en vanaf dan mislukt elke schrijfactie met dezelfde regel:

error: could not delete references: cannot lock ref 'refs/remotes/origin/x':
Unable to create '…/refs/remotes/origin/x.lock': File exists.

De repository is niet beschadigd. Er ligt simpelweg een bestand in de weg.

Gitcito probeert het eerst een paar keer opnieuw, want een lock in handen van een lopende git komt meestal binnen milliseconden vrij. Zo niet, dan opent de fout een dialoog in plaats van een muur tekst: elke lock die nog op schijf staat, hoe oud elk ervan is, en één knop die ze verwijdert en de mislukte actie opnieuw uitvoert.

Leeftijd is het hele argument. Een lock jonger dan 30 seconden hoort vermoedelijk bij een git die nog werkt, en Gitcito weigert die te verwijderen — het biedt aan te wachten en het opnieuw te proberen. Oudere worden aangeboden om te verwijderen, oudste eerst, en de dialoog zegt onomwonden wat je eerst moet nagaan: dat er nu geen editor, terminal of andere Git-client in deze repository bezig is. Een lock weghalen onder een levende schrijfactie is precies hoe een index scheurt.

De scan dekt de eigen git-map van de repository en de gemeenschappelijke map, dus locks van een gekoppelde worktree worden ook gevonden. Submodules worden overgeslagen — die horen bij een andere repository en ruim je op door die te openen.

Ongedaan maken / opnieuw

De meeste operaties leggen een regel op een undo-stapel, dus ⌘Z draait de laatste terug waar git dat toestaat.

Zie ook: Wat er veranderd is sinds · Stashes