126

I need to recover two Git branches that I somehow deleted during a push.

These two branches were created on a different system and then pushed to my "shared" (github) repository.

On my system, I (apparently) retrieved the branches during a fetch:

~/myfolder> git fetch
remote: Counting objects: 105, done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 62 (delta 29), reused 0 (delta 0)
Unpacking objects: 100% (62/62), done.
From github.com:mygiturl
 * [new branch]      contact_page -> origin/contact_page
   731d1bb..e8b68cc  homepage   -> origin/homepage
 * [new branch]      new_pictures -> origin/new_pictures

Right after that I did a push to send my local changes up to the central repo. For some reason, these branches were deleted from both my local system and the central repo:

~/myfolder> git push
Counting objects: 71, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (43/43), done.
Writing objects: 100% (49/49), 4.99 KiB, done.
Total 49 (delta 33), reused 0 (delta 0)
To git@github.com:mygiturl.git
 - [deleted]         contact_page
 + e8b68cc...731d1bb homepage -> homepage (forced update)
   bb7e9f2..e0d061c  master -> master
 - [deleted]         new_pictures
   e38ac2e..bb7e9f2  origin/HEAD -> origin/HEAD
   731d1bb..e8b68cc  origin/homepage -> origin/homepage
   e38ac2e..bb7e9f2  origin/master -> origin/master
 * [new branch]      origin/contact_page -> origin/contact_page
 * [new branch]      origin/new_pictures -> origin/new_pictures

It's not terribly easy to get the branches off of their birthplace machine, so I'd like to try and recover them from my local if possible.

All of the git "undo" information I've googled has to with recovering lost commits. I don't think that applies here, since I don't have commit UIDs for these branches.

I'd like to know how I can get these back. I'd also like to know how they were deleted in the first place and how I can avoid this in the future.

EDIT: by request, here's my repo configuration

user.name=Craig Walker
user.email=github@softcraft.ca
alias.unadd=reset HEAD
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git@github.com:MyGitURL.git
remote.origin.mirror=true
branch.master.remote=origin
branch.master.merge=refs/heads/master
alias.undo=reset --hard
alias.test=push -f ci HEAD:master
alias.st=status
alias.ci=commit
alias.br=branch
alias.co=checkout
alias.ch=checkout
alias.df=diff
alias.lg=log -p
alias.who=shortlog -s --
remote.ci.url=ContinuousIntegrationGitURL
remote.ci.fetch=+refs/heads/*:refs/remotes/ci/*
branch.photo.remote=origin
branch.photo.merge=refs/heads/photos
remote.foo.url=FooGitURL
remote.foo.fetch=+refs/heads/*:refs/remotes/cynthia/*
branch.homepage.remote=origin
branch.homepage.merge=refs/heads/homepage
Craig Walker
  • 49,871
  • 54
  • 152
  • 212
  • It looks like you have an 'unusual' or mismatched fetch and push configuration. What does `git config -l` show for the local repository? – CB Bailey Jan 03 '10 at 00:20
  • Quite possibly; I've posted it. – Craig Walker Jan 03 '10 at 00:28
  • 2
    Your `remote.origin.fetch` refspec is not appropriate for use with `remote.origin.mirror = true`. Do you want to mirror or do you want to use the GitHub repo as a normal remote? My answer should have the commands you need either way. – Chris Johnsen Jan 03 '10 at 01:24
  • I'm guessing that with the 2nd repository, mirroring is no longer an option (this probably caused the delete in the first place). – Craig Walker Jan 03 '10 at 04:59

9 Answers9

120

I'm not an expert. But you can try

git fsck --full --no-reflogs | grep commit

to find the HEAD commit of deleted branch and get them back.

iamamac
  • 9,632
  • 4
  • 35
  • 30
  • I tried fsck earlier; do you know how to find out which commit is the correct one? I've got 20 to try. – Craig Walker Jan 02 '10 at 19:08
  • 1
    This did it; once I had the commit messages, `git branch ` got them back. Thanks! – Craig Walker Jan 03 '10 at 05:23
  • Good to hear. Be sure to also resolve the conflict between your `remotes.origin.mirror` and `remotes.origin.fetch` settings, otherwise you are bound to run into the problem again (or unintentionally clobber commits pushed from other repos). – Chris Johnsen Jan 03 '10 at 05:27
  • @Craig: Glad to be helpful :) – iamamac Jan 03 '10 at 05:38
  • This one saved me redoing a couple of hours work just now. If I couple upvote more than once I would! :-) – Matthew Gertner Feb 24 '12 at 15:42
  • Saved my life! :) It was hard to use "git show" on all of the reported commits but at the end, I found the correct one and recovered it. – Xtro Nov 16 '15 at 18:51
  • Best git command for the absent-minded! Doing a `git checkout ` creates the branch with the changes made in the commit. – Gus Mar 07 '17 at 17:40
  • Didn't restore a remote branch. – CoolMind Jul 08 '17 at 09:12
  • 6
    I lost a release candidate branch today. Did not know the commit id. Got it recovered by using: `git fsck --full --no-reflogs | cut -d' ' -f3 | xargs -P8 git log --oneline | grep 'Release 2.60.0.157' ` – spezifanta Dec 05 '17 at 15:20
42

just two commands save my life

1. This will list down all previous HEADs

git reflog

2. This will revert the HEAD to commit that you deleted.

git reset --hard <your deleted commit>
ex. git reset --hard b4b2c02
chinnawatp
  • 1,430
  • 16
  • 15
  • 4
    I never checked into the branch locally so my HEAD has never been there, therefore I can not find the commit ID with `git reflog`. Is there anything else I can try? – zyy Jun 25 '20 at 18:26
  • 3
    Same as @zyy The commit has been deleted by other team member in remote, so I have to get it back in my local machine ( I never had that commit locally) and push it back... – OmGanesh Jul 02 '20 at 14:09
24

  1. find out commit id

    git reflog

  2. recover local branch you deleted by mistake

    git branch <NEED-RECOVER-BRANCH-NAME> commitId

  3. push need-recover-branch-name again if you deleted remote branch too before

    git push origin <NEED-RECOVER-BRANCH-NAME>

Naga Lokesh Kannumoori
  • 585
  • 2
  • 9
  • 34
JackChouMine
  • 947
  • 8
  • 22
  • 2
    This worked for me. I prefer over the accepted answer because it was far fewer steps. I was able to see my commit message from `git reflog`, rather than having to guess and `git show`. – theUtherSide Apr 11 '19 at 01:20
  • this saved me 5 days working non-stop 13 hours. thank you so much. I just by mistake removed my remote and local branch but I could recover it with this – navid_gh Dec 11 '20 at 18:21
15

Your deleted branches are not lost, they were copied into origin/contact_page and origin/new_pictures “remote tracking branches” by the fetch you showed (they were also pushed back out by the push you showed, but they were pushed into refs/remotes/origin/ instead of refs/heads/). Check git log origin/contact_page and git log origin/new_pictures to see if your local copies are “up to date” with whatever you think should be there. If any new commits were pushed onto those branches (from some other repo) between the fetch and push that you showed, you may have “lost” those (but probably you could probably find them in the other repo that most recently pushed those branches).

Fetch/Push Conflict

It looks like you are fetching in a normal, ‘remote mode’ (remote refs/heads/ are stored locally in refs/remotes/origin/), but pushing in ‘mirror mode’ (local refs/ are pushed onto remote refs/). Check your .git/config and reconcile the remote.origin.fetch and remote.origin.push settings.

Make a Backup

Before trying any changes, make a simple tar or zip archive or your whole local repo. That way, if you do not like what happens, you can try again from a restored repo.

Option A: Reconfigure as a Mirror

If you intend to use your remote repo as a mirror of your local one, do this:

git branch contact_page origin/contact_page &&
git branch new_pictures origin/new_pictures &&
git config remote.origin.fetch '+refs/*:refs/*' &&
git config --unset remote.origin.push &&
git config remote.origin.mirror true

You might also eventually want to do delete all your refs/remotes/origin/ refs, since they are not useful if you are operating in mirror mode (your normal branches take the place of the usual remote tracking branches).

Option B: Reconfigure as a Normal Remote

But since it seems that you are using this remote repo with multiple “work” repos, you probably do not want to use mirror mode. You might try this:

git config push.default tracking &&
git config --unset remote.origin.push
git config --unset remote.origin.mirror

Then, you will eventually want to delete the bogus refs/remotes/origin refs in your remote repo: git push origin :refs/remotes/origin/contact_page :refs/remotes/origin/new_pictures ….

Test Push

Try git push --dry-run to see what it git push would do without having it make any changes on the remote repo. If you do not like what it says it is going to do, recover from your backup (tar/zip) and try the other option.

Chris Johnsen
  • 214,407
  • 26
  • 209
  • 186
  • 1
    I don't think the remote tracking branches were kept, if they were copied at all. 'git branch -a' doesn't show them, and I can't find any files with those names in the .git dir either. Lastly, the "git log" commands you recommended return "fatal: ambiguous argument 'origin/contact_page': unknown revision or path not in the working tree" :-\ Thanks though. – Craig Walker Jan 03 '10 at 05:03
  • 1
    Well, those branches were there, your push log shows it. When looking for refs in the `.git` dir, be sure to check `.git/packed_refs` in addition to `.git/refs/`. `git show-ref` will dump out all your local refs (packed or ‘loose’). You should still be able to find the refs in the repo that originally pushed them to your GitHub repo (on a different machine? someone else's repo?). Failing that, as long as you have not done a gc or prune, you should be able to the `git fsck` output to examine the dangling commits and reattach them: `git branch contact_page-recovered `. – Chris Johnsen Jan 03 '10 at 05:21
  • packed_refs didn't have it either. The commits were definitely dangling; no idea how that happened. Thanks for your help though! – Craig Walker Jan 03 '10 at 06:00
13

If the delete is recent enough (Like an Oh-NO! moment) you should still have a message:

Deleted branch <branch name> (was abcdefghi).

you can still run:

git checkout abcdefghi

git checkout -b <some new branch name or the old one>

Timmy
  • 366
  • 5
  • 10
6

The data still exists out in github, you can create a new branch from the old data:

git checkout origin/BranchName #get a readonly pointer to the old branch
git checkout –b BranchName #create a new branch from the old
git push origin BranchName #publish the new branch
jhilden
  • 12,207
  • 5
  • 53
  • 76
4

If your organization uses JIRA or another similar system that is tied into git, you can find the commits listed on the ticket itself and click the links to the code changes. Github deletes the branch but still has the commits available for cherry-picking.

Roralee
  • 508
  • 1
  • 4
  • 15
1

I think that you have a mismatched config for 'fetch' and 'push' so this has caused default fetch/push to not round trip properly. Fortunately you have fetched the branches that you subsequently deleted so you should be able to recreate them with an explicit push.

git push origin origin/contact_page:contact_page origin/new_pictures:new_pictures
CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • As with my comment to @Chris Johnson, it appears that the branches no longer (never?) exist locally. When I `git push origin origin/contact_page:contact_page` I get this: `error: src refspec origin/contact_page does not match any` – Craig Walker Jan 03 '10 at 05:08
  • OK, I think I see what's happened, (although the full error would be helpful). push has updated the deleted branch and removed the ref locally as well as it's a tracking ref. What does `git rev-parse refs/remotes/origin/origin/contact_page` say ? Because of the bogus 'mirror' config, the branch my now be referenced here in the local repository. – CB Bailey Jan 03 '10 at 06:54
  • Hi Charles; Since I wrote this I've munged (and fixed) my config so I can't get the (meaninful) rev-parse output any more. However, I don't think there was a double-nested "origin" directory in remotes. – Craig Walker Jan 05 '10 at 17:21
-2

It may seem as being too cautious, but I frequently zip a copy of whatever I've been working on before I make source control changes. In a Gitlab project I'm working on, I recently deleted a remote branch by mistake that I wanted to keep after merging a merge request. It turns out all I had to do to get it back with the commit history was push again. The merge request was still tracked by Gitlab, so it still shows the blue 'merged' label to the right of the branch. I still zipped my local folder in case something bad happened.

Artorias2718
  • 575
  • 5
  • 11