In Git, come posso recuperare un file di staging che è stato ripristinato prima di eseguire il commit?

Stavo tentando di inserire una modifica nel mio repository usando Git Tower. Quando l’ho fatto, c’è stato un conflitto e per sbaglio ho colpito tutto il palco (come volevo impegnarmi dopo aver risolto il conflitto). Quando l’ho fatto, il conflitto si è segnato come risolto.

Volevo risolvere manualmente la modifica, quindi ho premuto “Abort Merge”, tuttavia, quando l’ho fatto, ha annullato tutte le mie modifiche! C’è un modo per riaverli?

Se dovessi fare qualcosa, probabilmente dovresti riuscire a recuperarlo. (Se hai appena modificato la copia di lavoro, non saresti in grado di ripristinarlo.)

Prima di tutto: non eseguire git gc . Esegui il backup del repository e copia di lavoro prima di andare avanti. (Assicurati di eseguire il backup della directory .git .) Evita anche di chiudere il terminale dove questo è successo, e / o riavviare – se tutto fallisce, hai la possibilità di trovare cose nella storia / memoria.

Ad ogni modo, la prima cosa da provare è:

 git fsck --lost-found

Stamperà qualcosa come

 Controllo delle directory object: 100% (256/256), terminato.
 Controllo oggetti: 100% (30165/30165), fatto.
 blob dangling 8f72c7d79f964b8279da93ca8c05bd685e892756
 commit dangling 4993502a6394491190d3f4d6fb3d1e14019c2e9b

Dato che hai perso i file di staging e non hai eseguito un commit, sei interessato a dangling blob voci di dangling blob .

Esegui git show per ognuno di essi – alcuni di loro dovrebbero essere i tuoi file.

Per espandere la risposta di Alexander con un’alternativa più semplice: sì, se hai messo in scena le tue modifiche allora puoi probabilmente riavere i tuoi file. Quando esegui git add , i file vengono effettivamente aggiunti al database degli oggetti di Git. Nel momento in cui lo fai, git metterà il file nell’indice:

 % git add bar.txt % git ls-files --stage 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 bar.txt 100644 6af0abcdfc7822d5f87315af1bb3367484ee3c0c 0 foo.txt 

Si noti che la voce per bar.txt contiene l’ID object del file. Git ha effettivamente aggiunto il file al suo database degli oggetti. In questo caso, Git lo ha aggiunto al repository come object libero:

 % ls -Flas .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a 4 -r--r--r-- 1 ethomson staff 21 14 Jun 23:58 .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a 

Questi file saranno eventualmente raccolti automaticamente (quindi, in effetti, non eseguire git gc esplicito). Per fortuna, per impostazione predefinita, ciò avverrà nel giro di pochi mesi , non di giorni. Fino a quando questi file non vengono raccolti, è ansible recuperarli.

Il modo più semplice per farlo è scaricare e installare il programma git-recover in modalità intertriggers:

 % git recover -i Recoverable orphaned git blobs: 61c2562a7b851b69596f0bcad1d8f54c400be977 (Thu 15 Jun 2017 12:20:22 CEST) > Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod > tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim > veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea > commodo consequat. Duis aute irure dolor in reprehenderit in voluptate Recover this file? [y,n,v,f,q,?]: 

git-recover cerca i file nel database dell’object che non sono stati impegnati (o nell’indice). Puoi trovare ulteriori informazioni su git-recover nel post del blog che lo annuncia .