Een Git-commit kan uit de zichtbare branchgeschiedenis verdwijnen terwijl de objecten lokaal nog bestaan. Een reset, rebase of verwijderde branch kan de handige referentie wegnemen zonder elk onderliggend object onmiddellijk te wissen. Daardoor zijn de eigen inspectiehulpmiddelen van Git de eerste herstelroute. Begin met het bewaren van de repository en het huidige niet-gecommitte werk. Zoek daarna naar de bedoelde commit en maak een nieuwe referentie aan in plaats van de huidige branch destructief te verplaatsen.
Snel antwoord: inspecteer eerst en maak een reddingsbranch
Gebruik de relevante lokale reflog om een plausibele eerdere commit te vinden, bekijk de inhoud en maak een afzonderlijk benoemde reddingsbranch aan wanneer de kandidaat juist is. Bestaande stashes of geautoriseerde overlevende clones bieden andere bronnen. Als er geen referentie meer is, kan een alleen-lezen objectinspectie enkele zwevende commits onthullen die nog bestaan. Geen van deze routes garandeert herstel nadat de vereiste objecten zijn verwijderd of wanneer het ontbrekende werk nooit in Git is beland.
De herstelwerktuigen van Git zijn gratis. De opdrachten hebben echter verschillende effecten, en een herstelartikel mag niet een nieuwe harde reset als eerste stap aanmoedigen. Bewaar de huidige werkstatus en bekijk voorbeelden voordat u ze aanpast. Onderscheid ook gecommit werk, gestagede inhoud, niet-gevolgde bestanden, genegeerde items en niet-opgeslagen editorbuffers. Een commit kan met succes worden hersteld terwijl een afzonderlijk niet-gevolgd bestand ontbreekt.
Bepaal welke Git-status ontbreekt
Verloren referentie of ontbrekende objecten
Noteer wat er is gebeurd: een branch verwijderd, een rebase, een reset, een vervangen repository of een ontbrekende werkmap. Een commit die niet in het huidige log staat, kan nog bereikbaar zijn vanaf een andere branch of tag. Begin met bestaande referenties voordat u onbereikbare objecten doorzoekt. Bevestig ook de juiste repository en clone. Twee mappen met dezelfde projectnaam kunnen verschillende lokale geschiedenissen en reflogs bevatten.
Schrijf een herkenbaar commitbericht, gewijzigd pad, functie of test op. Dat geeft u een praktische acceptatietest wanneer meerdere kandidaten op elkaar lijken. Een bekend bericht alleen is onvoldoende, omdat een rebase andere commits met verwante beschrijvingen kan maken. Bekijk de werkelijke wijzigingen en de relevante oudergeschiedenis. Het doel is de bedoelde projectstatus, niet alleen een object-ID die lijkt op een ID uit een schermafbeelding van een terminal.
Bewaar huidig werk en de context van de repository
Maak een passende volledige kopie van de repository en vermijd gelijktijdige wijzigingen. Neem de relevante Git-metadata mee, niet alleen de zichtbare bronbestanden. Bewaar niet-gecommit en niet-gevolgd werk ook afzonderlijk. Een normale clone kopieert niet noodzakelijk lokale reflogs of onbereikbare objecten en is daarom niet automatisch een volledige bewijskopie voor dit onderzoek. Noteer de bronmap en de Git-versie die u voor tests gebruikt.
Bekijk bij gekoppelde worktrees de werkelijke relatie met de Git-map voordat u alleen de worktreemap kopieert. De Git-metadata kan elders staan. Documenteer die relaties en gebruik ondersteunde Git-werkwijzen. Vermijd ook onderhoudsopdrachten die objecten opruimen zolang het herstel niet is opgelost. Een nieuwe build of installatie van afhankelijkheden is meestal niet relevant voor het vinden van een verloren commit en kan onnodige wijzigingen in de werkomgeving aanbrengen.
Gratis route 1: bekijk de lokale reflog
- Bevestig de repository en bewaar het huidige werk.
- Voer een alleen-lezen reflog-inspectie uit, bijvoorbeeld git reflog show –all, in de relevante clone.
- Zoek plausibele vermeldingen rond de reset, rebase of branchwijziging.
- Bekijk de werkelijke wijzigingen van elke kandidaat voordat u een reddingsreferentie aanmaakt.
Reflogs registreren updates van lokale referenties en kunnen onthullen waar een branch of HEAD eerder naar wees. Ze zijn lokaal bewijs, geen universele geschiedenis aan de serverkant. Een andere clone kan andere vermeldingen hebben en de bewaring is niet onbeperkt. Bekijk daarom snel de clone waarin het incident gebeurde. Beloof geen vaste herstelperiode zonder de werkelijke configuratie en overlevende objecten te controleren.
Lees de volgorde van gebeurtenissen zorgvuldig
Vergelijk vermeldingen vóór en na de handeling die de zichtbaarheid veranderde. Een rebase kan een reeks verwante statussen opleveren, terwijl een reset de branchtip direct kan verplaatsen. Bekijk een kandidaat met een opdracht als git show gevolgd door de werkelijke object-ID. Behandel de ID als een waarde die u uit uw repository selecteert, niet als een plaatsaanduiding om letterlijk te plakken. Vergelijk ook de getroffen bestanden en de oudergeschiedenis.
Als meerdere vermeldingen de ontbrekende wijziging bevatten, bepaalt u welke de volledige bedoelde ontwikkellijn vertegenwoordigt. Een enkele commit kan afhangen van eerdere commits die de geschiedenis van de kandidaat bevat. Bewaar een branch op de juiste tip in plaats van één patch blind te kopiëren. Zo blijft de herstelde ontwikkelvolgorde beschikbaar voor beoordeling zonder de huidige branch onmiddellijk te hoeven verplaatsen.
Gratis route 2: maak een afzonderlijke reddingsreferentie
- Bekijk de kandidaat en bevestig dat de vereiste objecten beschikbaar blijven.
- Kies een nieuwe, ongebruikte naam voor een reddingsbranch.
- Maak de branch aan op het gecontroleerde object, bijvoorbeeld met git branch en de gekozen naam en ID.
- Bekijk de nieuwe branch en vergelijk die in een beheerste werkruimte met het huidige werk.
Een nieuwe branch maken geeft een duurzame referentie naar de kandidaat zonder de huidige branch te resetten. De opdracht wijzigt referenties in de repository, dus bewaar bewijs en kies het doel bewust. De opdracht voegt de herstelde wijzigingen niet automatisch samen met de productie. Houd die integratiebeslissing apart. Controleer ook of de gekozen naam niet al een andere bruikbare branch aanduidt voordat u een voorbeeldopdracht aanpast.
Een opdrachtpatroon is git branch recovery-example COMMIT_ID. Hier staat recovery-example voor een nieuwe ongebruikte branchnaam, en COMMIT_ID moet worden vervangen door de werkelijke gecontroleerde commit-ID uit uw eigen repository. Plak de plaatsaanduiding niet letterlijk. Bekijk de kandidaat eerst met git show en de echte ID. Het maken van deze reddingsbranch bewaart een referentie zonder dat git reset –hard nodig is, en machtigt u niet om gedeelde remote-geschiedenis te pushen of te vervangen.
Beoordeel voordat u integreert
Vergelijk de herstelde branch met de bedoelde basis en de huidige branch. Bekijk tests, configuratie, migraties en afhankelijkheden die bij de wijziging horen. Een commit kan echt zijn terwijl die niet meer bij de huidige toepassing past. Gebruik waar nodig een afzonderlijke testwerkruimte. Herstel geeft toegang tot een historische status; normale technische beoordeling bepaalt hoe u die veilig in het huidige werk integreert.
Pusht u gedeelde geschiedenis niet geforceerd alleen om de herstelde branch op de vorige remote-status te laten lijken. Bewaar eerst een lokale reddingsreferentie. Elke publicatie of wijziging van gedeelde geschiedenis hoort bij de normale geautoriseerde werkwijze van de repository. Dit onderscheid voorkomt dat een lokaal herstel per ongeluk nieuwer werk van collega’s verwijdert of onafgeronde inhoud blootlegt die alleen gecontroleerd hoefde te worden.
Gratis route 3: bekijk een bestaande stash
- Bewaar de repository en de huidige werkstatus.
- Toon bestaande stash-vermeldingen via de ondersteunde interface van Git.
- Bekijk een relevante stash voordat u die toepast.
- Herstel gecontroleerde inhoud in een afzonderlijke teststatus zonder de enige stash-kandidaat te laten vallen.
Een stash kan werk bewaren dat nooit een normale branchcommit is geworden, maar de dekking hangt af van hoe die is gemaakt. Niet-gevolgde of genegeerde bestanden zitten niet automatisch in elke stash. Bekijk daarom de werkelijke inhoud in plaats van aan te nemen dat de stash de hele werkruimte bevat. Vergelijk ook de basiscommit en de bedoelde bestanden. Een vergelijkbaar genoemde stash kan bij een andere taak horen.
Houd inspectie en toepassing gescheiden
Alleen-lezen inspectie van een stash helpt een kandidaat te herkennen zonder de werkboom te wijzigen. Een stash toepassen kan conflicten opleveren of aannames over de huidige basis overschrijven, dus gebruik een beheerste werkruimte en bewaar eerst de huidige wijzigingen. Vermijd een pop-en-drop-werkwijze als eerste test wanneer die de nuttigste kandidaat kan verbruiken. Bewaar de stash totdat de herstelde inhoud is gecontroleerd en onafhankelijk bewaard.
Als een stash-vermelding zelf is verdwenen, kunnen de objecten ervan nog in de repository staan of niet. Behandel dat als een afzonderlijke beoordeling van objectherstel in plaats van te beloven dat dezelfde lijstopdracht die kan vinden. Onderscheid een stash ook van editorgeschiedenis. Een bronbuffer die nooit is opgeslagen of in Git is opgenomen, vereist een andere herstelbron, zelfs wanneer de gecommitte geschiedenis van de repository volledig gezond blijft.
Gratis route 4: bekijk een geautoriseerde overlevende clone
- Zoek een legitieme bestaande clone of referentie die de ontbrekende commit kan bevatten.
- Bewaar de lokale status ervan voordat u referenties wijzigt of daaroverheen haalt.
- Bekijk de werkelijke geschiedenis en inhoud van de kandidaat.
- Draag het gecontroleerde herstel over of verwijs ernaar via een passende beheerste Git-werkwijze.
Een geautoriseerde clone van een collega, een andere persoonlijke machine of een bestaande remote-referentie kan een commit bewaren die de getroffen clone niet meer aanduidt. Een remote-trackingnaam garandeert echter niet dat de onderliggende gewenste status beschikbaar blijft. Bekijk werkelijke objecten en geschiedenis. Gebruik ook niet zonder toestemming de privérepository of inloggegevens van iemand anders. De herstelbron moet er een zijn die u legitiem beheert of waarvoor u toestemming hebt.
Vergelijk objectidentiteit en inhoud
Gerebaseerde versies van dezelfde logische wijziging kunnen verschillende object-ID’s hebben. Een bekende ID-prefix is omgekeerd alleen een afkorting die ondubbelzinnig in de repository moet verwijzen. Vergelijk de werkelijke diff en de omringende geschiedenis. Noteer ook welke clone de kandidaat leverde. Zo kunt u uitleggen waarom de herstelde lijn afwijkt van een lokale reflog-vermelding en blijft het onderzoek traceerbaar.
Als de clone een bruikbare branch bevat, bewaart u een nieuwe reddingsreferentie voordat u integreert. Synchroniseer niet klakkeloos elke branch als een snelkoppeling voor herstel. Een beperkte overdracht van de gecontroleerde geschiedenis is gemakkelijker te beoordelen en verwart ongerelateerd werk minder snel. Voer daarna de passende tests uit en bekijk de resulterende diff ten opzichte van de bedoelde projectstatus.
Gratis route 5: bekijk overlevende zwevende objecten
- Bewaar een volledige relevante kopie van de repository en vermijd opruimend onderhoud.
- Gebruik een alleen-lezen opdracht voor integriteits- en objectinspectie die bij de repository past.
- Bekijk plausibele zwevende commitobjecten en hun inhoud.
- Maak pas een nieuwe referentie aan nadat u een bruikbare gecontroleerde kandidaat hebt gevonden.
Objectinspectie in Git kan commits of andere objecten onthullen die zonder normale branchreferentie bestaan. Die kan echter geen objecten herstellen die al uit elke beschikbare bron zijn verwijderd. Zwevende blobs en trees bewaren ook niet automatisch bestandsnamen, volledige projectcontext of een direct bruikbare commitgeschiedenis. Behandel de uitvoer als bewijs om te bekijken, niet als garantie dat elk gemeld object bij de verloren taak hoort.
Verwar waarschuwingen niet met het doel
Een objectdatabase kan ongerelateerd onbereikbaar materiaal uit normale activiteit bevatten. Vergelijk herkenbare paden en inhoud voordat u een kandidaat kiest. Noteer de werkelijke foutmeldingen apart van informatieve meldingen over zwevende objecten. Als de repository echt beschadigd is, bewaart u die en zoekt u de passende ondersteunde reparatieroute in plaats van willekeurige schrijfopdrachten uit te voeren tot een fout verdwijnt.
Bewaar het oorspronkelijke repositorybewijs ook nadat u een bruikbaar object hebt gevonden. Een latere vergelijking kan onthullen dat een andere kandidaat een ontbrekende test of vervolgwijziging bevat. Documenteer ook of het resultaat een hele commitreeks herstelt of alleen een bronfragment. Dat zijn verschillende uitkomsten, en het integratieplan moet rekening houden met de resterende context die u nog moet reconstrueren.
Voorbeeld: een branch herstellen na een ongewenste reset
Stel dat een ontwikkelaar een featurebranch terugzet naar een ouder punt en later merkt dat twee bruikbare commits uit het zichtbare log zijn verdwenen. De repository bevat hun objecten nog, en de reflog van HEAD toont de eerdere branchtip. Bewaar eerst het huidige werk. Bekijk de diff en oudergeschiedenis van de kandidaat en maak daarna een nieuwe reddingsbranch aan op de gecontroleerde tip. De huidige branch heeft voor deze eerste herstelstap geen nieuwe destructieve reset nodig.
Vergelijk de reddingsbranch daarna met het huidige werk en voer gerichte tests uit in een beheerste werkruimte. Als collega’s elders nieuwere wijzigingen hebben toegevoegd, integreert u via het normale beoordelingsproces in plaats van de historische status geforceerd te pushen. Bewaar ten slotte het geaccepteerde herstel en documenteer de bronvermelding in de reflog. Zo herstelt u de toegang tot de bedoelde commits terwijl de integratiebeslissing apart en beoordeelbaar blijft.
Valideer meer dan het commitbericht
Bekijk gewijzigde bestanden, oudergeschiedenis, tests, configuratie en vereiste projectitems. Vergelijk de kandidaat daarna met het werkelijke ontbrekende gedrag of de ontwikkelmijlpaal. Een commit die bouwt, kan nog een onvolledige tussenstatus vertegenwoordigen. Bewaar niet-gevolgd materiaal ook afzonderlijk waar de taak dat vereist. Git-herstel kan vastgelegde geschiedenis teruggeven terwijl genegeerde gegevens, lokale instellingen of niet-opgeslagen buffers onopgelost blijven.
Bewaar de bewijsrepository, reddingsreferenties en geaccepteerde integratie totdat de beoordeling is afgerond. Bescherm daarna betekenisvolle branches of exports via de normale back-upwerkwijze. Bewaar belangrijke items buiten Git ook afzonderlijk. Een remote-repository en een lokale reflog beantwoorden verschillende vragen, dus geen van beide mag worden behandeld als een onbeperkte back-up van elke status die ooit in een editor verscheen.
Classificeer verloren werk voordat u een opdracht kiest
Gecommitte en niet-gecommitte statussen
Een branchtip kan verschuiven terwijl gecommitte objecten overleven, maar een niet-gevolgd bestand komt misschien nooit in de objectdatabase. Gestagede inhoud en stashes introduceren andere mogelijkheden. Noteer de werkelijke werkwijze die aan het verlies voorafging. Zo voorkomt u dat een geslaagde commitredding wordt voorgesteld als herstel van elk bestand dat ooit in de werkmap verscheen. Verschillende statussen vereisen verschillend bewijs.
Bekijk voor ontbrekende niet-gecommitte tekst de overlevende editorgeschiedenis of onafhankelijke werkruimte-kopieën naast Git. Bewaar ook huidige wijzigingen voordat u een historische status test. Dwing niet alle herstelvragen in een reflog-zoekopdracht. Een duidelijke classificatie helpt u snel de juiste bron te kiezen en voorkomt destructieve opdrachten die de huidige branch verplaatsen zonder het werkelijke ontbrekende materiaal aan te pakken.
Hernoemde paden en branchidentiteit
Een bestand kan ontbreken omdat het pad is gewijzigd of omdat de verkeerde branch is geopend. Controleer repository-identiteit, branch en relevante geschiedenis voordat u gegevensverlies aanneemt. Vergelijk ook de werkelijke diff rond een hernoeming. Een zoekopdracht op bestandsnaam kan nuttige inhoud onder een ander pad missen. Houd het bedoelde gedrag en een kenmerkend bronfragment in uw acceptatiechecklist.
Als meerdere repositories een projectnaam delen, noteert u de absolute bronmap voor elke kandidaat. Een clone die na het incident is gemaakt, kan het relevante lokale bewijs missen, zelfs wanneer die dezelfde remote branches bevat. Een oudere persoonlijke clone kan omgekeerd nuttige geschiedenis bewaren. Vergelijk de werkelijke beschikbaarheid van objecten en inhoud in plaats van aan te nemen dat elke clone voor herstel uitwisselbaar is.
Bekijk historische kandidaten samenhangend
Commitouders en afhankelijke wijzigingen
Een herstelde tip kan een hele werkreeks bevatten, terwijl één geïsoleerde commit van eerdere wijzigingen kan afhangen. Bekijk oudergeschiedenis en verwante bestanden. Een feature-implementatie kan bijvoorbeeld een schema-update of een testfixture uit een andere commit vereisen. Alleen het meest herkenbare bronbestand herstellen kan een onvolledig resultaat opleveren, ook wanneer de herstelde commit zelf echt is.
Bewaar een reddingsreferentie op een gecontroleerd bruikbaar punt en vergelijk de reeks in een beheerste werkruimte. Bepaal daarna hoe het huidige project die via normale beoordeling moet opnemen. Zo scheidt u toegang tot historisch werk van integratie. Dat voorkomt ook een nieuwe destructieve reset die ongerelateerde huidige wijzigingen weggooit, alleen omdat de herstelde reeks ooit de branchtip vertegenwoordigde.
Gerebaseerde wijzigingen en ID’s
Een rebase kan nieuwe object-ID’s maken voor wijzigingen die op eerdere commits lijken. Vergelijk daarom werkelijke diffs en omliggende context in plaats van een bericht of korte ID als volledig bewijs te behandelen. Bevestig ook dat een afgekorte ID ondubbelzinnig in de relevante repository verwijst. Een kandidaat uit een andere clone kan een langere ID of een andere referentiecontext vereisen voor betrouwbare inspectie.
Houd de oorspronkelijke bron van de kandidaat gedocumenteerd. Als twee versies dezelfde logische wijziging anders implementeren, bewaart u beide totdat de beoordeling de geaccepteerde vorm bepaalt. Herstel vereist niet dat u het eerste bekende bericht kiest. De sterkste kandidaat is degene die het bedoelde gedrag en de context herstelt en tegelijk begrijpelijk en compatibel blijft met het huidige project.
Stashdekking en conflicten
Bekijk wat een stash werkelijk bevat voordat u die toepast. De opties waarmee die is gemaakt bepalen of niet-gevolgde of genegeerde inhoud erin staat. Vergelijk ook de basistoestand met het huidige werk. Een stash van een andere taak kan bruikbare fragmenten naast ongerelateerde wijzigingen bevatten. Bewaar de kandidaat en gebruik een beheerste teststatus in plaats van die zonder beoordeling over een drukke werkboom toe te passen.
Als er conflicten optreden, houdt u de oorspronkelijke stash en de huidige basis beschikbaar. Een conflictoplossing is nieuw werk dat verificatie vereist, geen bewijs dat de oorspronkelijke wijzigingen automatisch zijn teruggekeerd. Noteer eventuele gereconstrueerde delen. Zo kan de beoordelaar herstelde bron onderscheiden van beslissingen tijdens de integratie en verbergt een oppervlakkig schone samenvoeging geen verloren gedrag.
Behandel objectinspectie als het verzamelen van bewijs
Zwevende objecten kunnen ongerelateerd zijn
Een repository kan onbereikbare objecten uit gewone activiteit bevatten die niets met het incident te maken hebben. Bekijk de werkelijke inhoud voordat u er een kiest. Een zwevende blob kan tekst bewaren zonder de oorspronkelijke bestandsnaam of projectcontext. Een zwevende commit kan een samenhangende geschiedenis bieden. Die uitkomsten hebben verschillende praktische waarde, dus label het resultaat naar wat u werkelijk hebt gevonden.
Bewaar de bewijsrepository voordat u onderhoud of reparatie uitvoert. Houd echte integriteitsfouten ook gescheiden van informatieve meldingen over onbereikbare objecten. Herhaaldelijk schrijfopdrachten uitvoeren tot de uitvoer rustiger lijkt, kan bruikbaar herstelmateriaal verwijderen zonder het doel te herstellen. Een beheerst alleen-lezen onderzoek biedt een duidelijker pad naar een gecontroleerde reddingsreferentie of een afgebakend gedeeltelijk bronherstel.
Objectoverleving heeft grenzen
Reflog-vermeldingen en objecten zijn geen onbeperkt archief. De werkelijke bewaring, het onderhoud en beschikbare clones bepalen wat overblijft. Beloof niet alleen herstel omdat het incident recent was. Bekijk de relevante bron snel en bewaar die. Als de vereiste objecten overal beschikbaar ontbreken, kan een reflog-bericht alleen hun volledige inhoud niet opnieuw maken.
Bepaal op dat punt alternatieve bronnen zoals geautoriseerde overlevende clones, vastgelegde patches, editorgeschiedenis of onafhankelijke bestandsback-ups. Houd het integratiedoel expliciet. Een gereconstrueerde implementatie kan het probleem van de gebruiker oplossen terwijl die afwijkt van de exacte verloren commit. Documenteer dat onderscheid in plaats van een historisch ogende herstelclaim uit onvolledig bewijs te maken.
Valideer en bewaar een reddingsresultaat
Test het bedoelde gedrag
Vergelijk de herstelde reeks met de werkelijke taakvereiste. Bekijk verwante tests, configuratie en projectitems. Voer daarna gerichte validatie uit in een passende omgeving. Een geslaagde build is nuttig, maar test het verloren gedrag misschien niet. Beoordeel ook elke conflictoplossing of gereconstrueerde bron, omdat dat nieuwe beslissingen op de herstelde geschiedenis zijn.
Houd publicatie gescheiden van lokale acceptatie. Een gecontroleerde reddingsbranch hoeft niet onmiddellijk gedeelde remote-geschiedenis te vervangen. Gebruik de normale geautoriseerde beoordelings- en integratiewerkwijze van de repository. Dat beschermt nieuwer werk van collega’s en voorkomt dat onafgerond of gevoelig lokaal materiaal wordt verspreid alleen omdat een herstelopdracht is geslaagd.
Bewaar samenhangende herstelpunten
Bewaar na acceptatie een betekenisvolle referentie of een andere ondersteunde repositoryback-up die bij de werkwijze past. Bescherm belangrijke items buiten Git ook afzonderlijk. Test een representatief herstel dat de projectstatus bevat die u werkelijk nodig hebt. Een remote branch, lokale reflog en volledige bewijskopie bieden verschillende dekking; geen daarvan mag worden beschreven als een universele back-up van elke toetsaanslag en elk genegeerd bestand.
Documenteer de geaccepteerde herstelbron en eventuele resterende hiaten. Bewaar oorspronkelijk bewijs totdat de beoordeling is afgerond. Zo heeft een toekomstige onderzoeker genoeg context om de herstelde reeks te onderscheiden van latere integratiewijzigingen. De duurzame uitkomst is een samenhangende, geteste projectstatus met begrijpelijke herkomst, niet een verzameling object-ID’s waarvan niemand weet hoe die met het bedoelde werk moet worden verbonden.
Wanneer opslagherstel verloren Git-commits kan helpen
Een opslagscan kan helpen wanneer de repositorymap of bronbestanden werkelijk ontbreken op ondersteunde lokale opslag. PandaOffice Drecov maakt de grafiek van Git niet opnieuw uit een paar willekeurige herstelde objectfragmenten en herstelt geen verwijderde geschiedenis van een remoteserver. Controleer de actuele ondersteuning en bekijk werkelijke kandidaten. Gebruik bij voorkeur de eigen herstelwerktuigen van Git wanneer de relevante objectdatabase nog bestaat en een samenhangende geschiedenis kan bieden.
Stap 1: Kies de werkelijke opslag van de repository
Bepaal welke schijf de werkmap en de relevante Git-metadata bevatte. Gekoppelde worktrees kunnen metadata elders plaatsen, dus bewaar de relatie. Vermijd nieuwe builds, downloads van afhankelijkheden of installatie van herstelsoftware op getroffen opslag. Als het apparaat onstabiel wordt, stopt u met herhaalde scans en beoordeelt u de staat ervan. Een gezonde clone op een andere schijf kan een samenhangender bron bieden dan een gefragmenteerd opslagherstel.
Stap 2: Bewaar de volledige context van kandidaten
Gebruik de beschikbare filters voor pad, datum, naam en indeling. Herstel waar mogelijk de relevante mapstructuur in plaats van alleen zichtbare bronbestanden te selecteren. Bewaar ook meerdere plausibele repositorykopieën. Een bronmap kan bruikbaar zijn zonder de ontbrekende lokale geschiedenis te bevatten, terwijl metadatafragmenten misschien geen geldige repository reconstrueren. Houd die beperkingen zichtbaar en noteer de herkomst van elke kandidaat.
Stap 3: Herstel elders en bekijk de resultaten in Git
Sla kandidaten op een andere gezonde fysieke schijf op. Bekijk de licentievoorwaarden en beperkingen van de voorbeeldweergave voordat u koopt. Bekijk kopieën daarna met passende Git- en brontools zonder herstelde code automatisch uit te voeren. Valideer de beschikbaarheid van objecten en de projectinhoud afzonderlijk. Het opslagprogramma levert mogelijke bestanden; Git-inspectie stelt vast of een samenhangende commitgeschiedenis overleeft en welk werk nog reconstructie vereist.
Gerelateerde herstelbronnen
Bekijk de relevante herstelopties: Herstel van harde schijf, Herstel van externe harde schijf.
Lees de gerelateerde herstelhandleiding voor een ander herstelgeval en de praktische controles daarbij.
Raadpleeg de leveranciersinstructies voor de geïnstalleerde versie: officiële hersteldocumentatie 1, officiële hersteldocumentatie 2, officiële hersteldocumentatie 3, officiële hersteldocumentatie 4.
