How do you restore a branch that was deleted with git branch -D?
answer
- The commits outlive the ref
- Read what the delete command printed
- The branch's own log went with it
- HEAD's log still names the tip
- git branch <name> <hash> recreates it
basics
~20 sDeleting a branch removes only its ref and its own reflog, not its commits. Recover the tip hash from the message git branch -D printed, from HEAD's reflog, or from git fsck, then recreate it with git branch <name> <hash>.
solid answer
~40 s`git branch -D feature` deletes `refs/heads/feature` and the branch's reflog at `.git/logs/refs/heads/feature`; the commits stay in the object database. The easiest source of the tip hash is the command's own output — it prints `Deleted branch feature (was 4b7de10)`. If that has scrolled away, `git reflog` still works, because HEAD's log recorded every commit and checkout you did while on that branch; look for the last `commit:` entry before the `checkout: moving from feature to main` line. Failing that, `git fsck --lost-found` will list the commit as dangling. Then just recreate the ref: `git branch feature 4b7de10`. If the branch had been pushed and you still have `refs/remotes/origin/feature`, `git branch feature origin/feature` is simpler still.
code
console · 9 lines$ git branch -D feature
Deleted branch feature (was 4b7de10).
$ git reflog
8f1c2a9 (HEAD -> main) HEAD@{0}: checkout: moving from feature to main
4b7de10 HEAD@{1}: commit: add retry backoff
$ git branch feature 4b7de10
$ git log --oneline feature -1go deeper
Know that a branch is just a name pointing at a commit, and that recreating it is git branch <name> <hash>. Remember that the delete command prints the tip hash you need.
Explain why the branch's own reflog is gone but HEAD's reflog still helps, and list the escalating sources of the tip hash: the printed message, HEAD's reflog, a remote-tracking ref, then fsck.
Demonstrate triage: establish whether the branch was ever pushed or checked out before choosing a route, avoid housekeeping commands while recovering, and re-establish upstream config after recreating the ref.
Own the policy angle. Argue for conventions that make branch loss recoverable by default — pushing topic branches early, keeping deletions out of scripted cleanups, and treating forced deletion as an exception rather than a habit.
## What deletion actually removes A branch in Git is a ref: a file under `.git/refs/heads/` (or an entry in `.git/packed-refs`) whose entire content is one commit hash. `git branch -d` refuses to delete a branch whose commits are not merged into its upstream or the current branch; `git branch -D` is the forced version that deletes regardless. Either way, what disappears is the ref plus that branch's own reflog file at `.git/logs/refs/heads/<name>`. Every commit the branch pointed at is still an object in `.git/objects` — now unreachable, but present. ## Source 1 — the message Git already printed This is the detail interviewers like to see. Deleting a branch prints `Deleted branch feature (was 4b7de10)`. That hash is the tip. If the terminal is still open, recovery is one command away and no forensics are needed. ## Source 2 — HEAD's reflog Because the branch's own reflog was deleted with it, `git reflog show feature` no longer works — this trips people up. HEAD's reflog, however, is a single file recording every HEAD movement in the repository regardless of which branch was checked out. So if you ever had the branch checked out, its commits appear there: - `commit: <subject>` entries for each commit you made while on it - a `checkout: moving from feature to main` entry marking when you left it The hash on the line just before that checkout entry is the branch tip. `git reflog` or `git log -g --oneline` both show this. The gap in coverage: a branch you created from a hash but never checked out, or one created by a fetch, may leave no HEAD reflog trace at all. ## Source 3 — remote-tracking refs If the branch had been pushed, your clone still has `refs/remotes/origin/feature` until something prunes it. `git branch feature origin/feature` recreates the branch at whatever was last fetched. Check with `git branch -r` first, and be aware that this recovers the pushed state, which may be behind your local tip. ## Source 4 — fsck When there is no reflog entry and no remote-tracking ref, fall back to `git fsck --lost-found`, which reports dangling objects and writes dangling commits into `.git/lost-found/commit/`. Inspect candidates with `git show <hash>` or `git log --oneline <hash> -5` until you find the tip you recognise. ## Recreating the branch Recovery is simply `git branch feature 4b7de10`. There is no special "undelete" — a branch is defined entirely by its name and the hash it holds, so writing the ref back restores it exactly. You do not get the branch's old reflog back, and you do not automatically get its upstream configuration back; if it had one, re-establish it with `git branch --set-upstream-to=origin/feature feature` or push with `-u`. ## The window Unreachable commits survive only until garbage collection prunes them, which is normally weeks away but can be closed early by an explicit prune. If you discover the deletion long after the fact, or someone ran aggressive housekeeping, the objects may be gone. While recovering, do not run housekeeping commands in that repository. ## A related trap Deleting a branch does not delete anything shared. Other clones keep their own refs, and a deletion is local until it is pushed as a ref deletion. Conversely, a branch someone else deleted upstream still exists in your clone as a remote-tracking ref until a prune removes it — which is often the fastest way to recover a branch a colleague deleted: ask whoever last fetched it. ## What a strong answer sounds like Name the three escalating sources in order — the printed hash, HEAD's reflog, then fsck — explain why the branch's own reflog is not available, and finish with `git branch <name> <hash>`. Mentioning that `-d` would have refused the delete in the first place, and that the safe habit is to let it refuse rather than reflexively typing `-D`, is the extra half point.
- Why does git reflog show <branch> fail for the deleted branch?Each branch has its own reflog at .git/logs/refs/heads/<name>, and deleting the branch deletes that file along with the ref. HEAD's reflog is a separate file that survives, which is why it remains usable — provided you actually had the branch checked out while working on it.
- What does git branch -d do differently, and why does it matter here?The lowercase form refuses to delete a branch whose commits are not already merged into its upstream or the current branch, printing an error instead. Letting it refuse is the cheapest safety net: -D bypasses exactly the check that would have prevented the loss.
- Does recreating the branch restore everything about it?It restores the name and the tip commit, which is the whole definition of a branch. It does not restore the branch's deleted reflog, and it does not restore upstream configuration — set that again with git branch --set-upstream-to, or push with -u.
saying these in an interview costs you the question
- Claims deleting a branch deletes its commits
- Tries git reflog show <branch> for the deleted branch and gives up
- Believes only a remote copy can bring the branch back
- Thinks there is a dedicated undelete command for branches
- Assumes -D and -d behave identically