0

At first, I didn't even write git init.
And then to use AWS beanstalk(After I completed my coding),I initialize git. And I use "git add ." command. but I knew I didn't make the "gitignore" file, so I ran git reset --hard to reset the "git add", so all my files are deleted now. What should we do to restore this? "git reflog" is not working. what should I do to recover my previous code.

  • 1
    As a note—in general, the commands that destroy data are protected by flags like `--force` and `--hard`. So if you ever use `--force` or `--hard`, stop for a moment and think before you type in the command. – Dietrich Epp Jul 12 '20 at 06:04
  • Does this answer your question? [Restore git files deleted after git merge --abort](https://stackoverflow.com/questions/39468125/restore-git-files-deleted-after-git-merge-abort) – LeGEC Jul 12 '20 at 06:41
  • No, that question will likely not. Changes were commit’ed in that case (prior to the merge). After a reset —hard, and changes in the index are indeed lost as they were never committed, and you’re back to where you were. – user2864740 Jul 12 '20 at 06:44
  • It would have been appropriate just to add the .gitignore in the same commit (resetting any accidental additions), or to have done a reset _without_ ‘—hard’. Use this as a learning experience and avoid annoyances in the future. (FWIW, I recommend _not_ using “git add .”, pretty much ever..) – user2864740 Jul 12 '20 at 06:48
  • You will find good answers here (especially one by me ;) : https://stackoverflow.com/questions/11094968/in-git-how-can-i-recover-a-staged-file-that-was-reverted-prior-to-committing/58853981#58853981 – Philippe Jul 12 '20 at 07:09
  • @Philippe I did what You said but that wasn't working – Edwards Nick Jul 12 '20 at 12:34

2 Answers2

3

Since you added the files, git should still have a trace of their content.

Run :

git fsck --full --unreachable --no-reflog | grep blob

This will give you a list of hashes, each of which point to a blob (a file's content). Unfortunately, the names of the files are not stored, so you will have to make sense of what blob should be restored, and to find their names back.

Here are ways to make sense of these hashes :

You can view the content of a blob :

git show <sha>

# restoring a blob is just :
git show <sha> > filename

If you remember a specific word or instruction in a file, you can use git grep <string> <sha> on the list of blobs :

$ git fsck --full --unreachable --no-reflog | grep blob | awk '{ print $3 }' > list.txt
$ cat list.txt | while read blob; do
  if git grep -q "string" $blob; then
    echo $blob
  fi
done

You can use a trick to sort them by modification date (which should be : the moment they were added)

# using the same list.txt as above :
cat list.txt |\
    sed -e 's|^\(..\)\(.*\)|.git/objects/\1/\2|' |\
    xargs ls -l -t 2> /dev/null

(more explanations for this trick in this SO question)

LeGEC
  • 46,477
  • 5
  • 57
  • 104
1

The good news is that git reset --hard is changing what Git thinks the HEAD revision for the branch is. The commit that was previously the HEAD is still in your local repo.

There are a couple of bits of bad news though:

  1. Finding what the HEAD commit was the previous is not straightforward. But this Q&A offers some possible solutions:

  2. If there were uncommitted changes when you did the git reset --hard they are not recoverable. Git only remembers stuff that you committed (or stashed).

Now, you say that git reflog is "not working". Well according to the documentation, git reset --hard doesn't affect the reflog. So I am guessing your "not working" means that it won't get back the uncommitted files. If so, I'm afraid you are out of luck. Those files are gone1.


The after-the-fact advice I would give is:

  • "commit early, commit often", and
  • make sure that you have a backup of your local git repo tree in a safe place before you embark on potentially dangerous Git procedures that you don't fully understand.

1 - Unless the missing files have been preserved in file system backups, editor / IDE buffers or history, or something similar.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I use "git add ." after using "git add ." I use "git reset --hard" due to "2. if there ~~~" does it mean I can't recover everything? – Edwards Nick Jul 12 '20 at 06:09
  • No. Nothing can be recovered in that case (the current WC is “all there is”). The index was reset, deleting the staged changes. They were never committed and thus no longer exist - there are no reflog entries if there is no commit’ish. Oops. Time to rewrite it, better. I recommend commit early, commit often, and use rebase to fix up WIP. – user2864740 Jul 12 '20 at 06:19
  • If the files are opened in editors, some support their own undo and backup handling.. or might allow the contents to be re-saved. – user2864740 Jul 12 '20 at 06:25