Lost all commits when forced push in github

Question

Recently I created a PR in a forked repo and added few commits. Later I accidentally deleted the branch from git bash(branch was present in my forked repo). So I recreated a branch with the same name and in that, I tried to push new commits. But it rejected the commits at first, so I forced pushed the commit, but this removed all the previous commits from the PR in github.

I don't know what happened here. Also is it possible to get back all the lost commits?

Answer 1

Before you do anything else - make a copy of your local repo.

Use git fsck --lost-found (or git fsck --dangling) to find your lost commits (dangling SHA's) and then git reflog to match them to your commit comments so you can identify them.

Note: depending what happened you may not get an entry for your commit using the raw "reflog" command (although there may be a parameter to do this with reflog). Instead, as I mentioned in the update at the bottom, you can use git log --walk-reflogs --oneline --decorate to list a log of all commits in date/time order.

If/when you find your lost commit (forget the old/lost branch name) you can merge that SHA directly into a new branch, or you can check that lost commit back out (or make a new branch from it).

Use git log --graph --all --oneline --decorate (or similar) to see how your repo looks after you checkout your lost commit to see if this matches what you expect.

Note: if you have done a git clean up you probably will have lost your "dangling commits" but if you have not done any git clean up then there is no reason that they should be lost.

E.g.:

1. Repo with lost data:

D:\software\sandpit\branchclonetest > git log --graph --oneline --all --decorate * 77d69c7 (HEAD -> fromNewBranch, origin/master, origin/fromNewBranch, origin/HEAD) new file * 88181c4 (origin/new_branch) new file * 175d1e1 (origin/test_branch_1) file for merge back to master * 5d5b028 file added in branch * 777984b yet another file * e0652e8 (origin/logoff) new test files added

2. Look for lost / dangling commits

D:\software\sandpit\branchclonetest > git fsck --lost-found Checking object directories: 100% (256/256), done. dangling commit 92cacfdb6265075b8fae5fd63b21219cf91ea0ec <-- WANT THIS ONE dangling commit 1ad608bd48fc8bdedd186d05cc486974d6890265 dangling commit 59622d01426d876aec3a7e9265d52648a66e13e5

3. Checkout lost commit 92cacf...

D:\software\sandpit\branchclonetest > git checkout 92cacfdb6265075b8fae5fd63b21219cf91ea0ec Note: checking out '92cacfdb6265075b8fae5fd63b21219cf91ea0ec'... etc...

4. Check the repo graph again to see what happened:

D:\software\sandpit\branchclonetest > git log --graph --oneline --all --decorate * 77d69c7 (origin/master, origin/fromNewBranch, origin/HEAD, fromNewBranch) new file * 88181c4 (origin/new_branch) new file * 175d1e1 (origin/test_branch_1) file for merge back to master * 5d5b028 file added in branch * 777984b yet another file | * 92cacfd (HEAD) test <--- COMMIT FOUND HERE |/ * e0652e8 (origin/logoff) new test files added

Note - Don't do anything like git gc (clean up) or other pruning type operation as this can really delete dangling / unreachable commits...

Update:

Just remembered this while looking at something else, so I thought I would add it to this post. You can log all the reflogs using the "--walk-reflogs" or "-g" option of git log.

This will show you everything including dangling commits because it does not traverse commits by branch/ancestry - it traverses commits by date order (newest at the top).

So to look at all the commits you can use git log --walk-reflogs or if you want the information a bit more consise: git log --walk-reflogs --oneline --decorate (added decorate just so that any tags/branches related to a commit are also shown).

Answer 2

Try git reflog origin/name_of_your_branch to find your old commit. It must be there.

If you can't find it, that's because you did a git push --force which is a really bad practice. You must now use git push --force-with-lease to prevent such problems.

If it isn't, you will have to play with git fsck like told in the other answer.