236

Coming from svn, just starting to become familiar with git.

When a branch is deleted in git, is it removed from the history?

In svn, you can easily recover a branch by reverting the delete operation (reverse merge). Like all deletes in svn, the branch is never really deleted, it's just removed from the current tree.

If the branch is actually deleted from the history in git, what happens to the changes that were merged from that branch? Are they retained?

Sam
  • 7,252
  • 16
  • 46
  • 65
Ken Liu
  • 22,503
  • 19
  • 75
  • 98

3 Answers3

310

Branches are just pointers to commits in git. In git each commit has a complete source tree, it is a very different structure from svn where all branches and tags (by convention) live in separate 'folders' of the repository alongside the special 'trunk'.

If the branch was merged into another branch before it was deleted then all of the commits will still be reachable from the other branch when the first branch is deleted. They remain exactly as they were.

If the branch is deleted without being merged into another branch then the commits in that branch (up until the point where the forked from a commit that is still reachable) will cease to be visible.

The commits will still be retained in the repository and it is possible to recover them immediately after the delete, but eventually they will be garbage collected.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • 5
    Thanks for the answer. Could you clarify what you mean by "each commit has a complete source tree"? As I understand it, each commit in git is a set of deltas that refer back to a parent commit, not an entire tree. – Ken Liu Apr 10 '10 at 23:25
  • Nope, each commit is the state of the tree at a given point. The deltas are only computed later on for displaying and rebasing and whatnot, but the commit id is the hash of the entire tree. – ben Apr 10 '10 at 23:27
  • 4
    @Ken Liu: A commit contains pointers to zero or more parent commits, a tree object and some metadata about the commit. The commit, therefore uniquely identifies both a couple source tree and, when viewed against its parent(s), the changes that it introduced. – CB Bailey Apr 10 '10 at 23:38
  • 1
    Got it. It sounded to me like each commit contained an entire source tree instead of pointers into another data structure. – Ken Liu Apr 12 '10 at 00:36
  • 11
    @Ken Liu: It depends on exactly what you been by 'contain', but yes, essentially each commit contains a complete tree. In the object database objects are indexed by id so objects are shared between all the objects (trees and commits) that reference them so the implied storage overhead isn't as bad as it initially sounds. git also has an efficient storage optimization (pack files) which make even more efficient usage of disk space. – CB Bailey Apr 12 '10 at 09:29
  • 2
    garbage collected by a fastidious git administrator (human) or does this happen automatically? – Dan Rosenstark Dec 14 '15 at 23:41
  • 36
    *"eventually they will be garbage collected"* - Eventually when? – BadHorsie Jan 07 '16 at 15:49
  • 12
    @BadHorsie, [it depends](https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery). – AliOli Jul 25 '16 at 16:38
103

In Git, branches are just pointers (references) to commits in a directed acyclic graph (DAG) of commits. This means that deleting a branch removes only references to commits, which might make some commits in the DAG unreachable, thus invisible. But all commits that were on a deleted branch would still be in the repository, at least until unreachable commits get pruned (e.g. using git gc).

Note that git branch -d would refuse to delete a branch if it cannot be sure that deleting it wouldn't leave unreachable commits. You need to use the stronger git branch -D to force deletion of a branch if it might leave unreachable commits.

Note also that unreachable commits, if they are present, are only those commits between the last tip of a deleted branch and either a commit that got merged to another existing branch, any tagged commit, or the branching point; whichever is later. For example in the following situation:

----O----*----*----/M----*    <-- master <-- HEAD
     \            /
      \--.----.--/--x---y     <-- deleted branch

only commits 'x' and 'y' would become unreachable after deleting the branch.

If you operated on a deleted branch within the gc.reflogExpire period, default 90 days, you would have the last tip of a deleted branch recorded in HEAD reflog (see git reflog show HEAD, or git log --oneline --walk-reflogs HEAD). You should be able to use HEAD reflog to recover the deleted pointer. Note also that in this case, unreachable commits in just a deleted branch would be protected from pruning (removing) within the gc.reflogExpireUnreachable period, which by default is 30 days.

If you can't find the tip of a just deleted branch in reflog for HEAD, you can try to use git fsck to find "unreachable commit <sha1>", and examine those (via git show <sha1> or git log <sha1>) to find the tip of the deleted branch.

Independent on how you find the tip of a deleted branch, you can undo deletion, or rather re-create a just deleted branch using

git branch <deleted-branch> <found-sha1-id>

Note however that reflog for a branch would be lost.

There is also git-resurrect.sh script in contrib/ which helps find traces of a branch tip with given name and resurrect (undelete) it.

deadly
  • 1,194
  • 14
  • 24
Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
2

If you are worried about accidentally deleted branches and do not have a local copy of your repo any longer, there are extensions to enterprise Git servers like Gerrit that will detect history rewrites and branch deletions, will back them up under a special ref so that they can be restored if needed and will not be pruned by garbage collection. Gerrit administrators can still remove selected commits if needed for legal reasons.

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
Johanned Nicolai
  • 79
  • 3