删除 git 中的分支是否会将其从历史记录中删除？
来自svn，刚刚开始熟悉git。
当git中删除一个分支时，它会从历史记录中删除吗？
在svn中，您可以通过恢复删除操作（反向合并）轻松恢复分支。与 svn 中的所有删除一样，分支从未真正删除，它只是从当前树中删除。
如果分支实际上从 git 的历史记录中删除，那么从该分支合并的更改会发生什么？他们被保留了吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
分支只是指向 git 中提交的指针。在 git 中，每个提交都有一个完整的源代码树，它与 svn 的结构非常不同，其中所有分支和标签（按照惯例）都位于存储库的单独“文件夹”中，并与特殊的“主干”一起。
如果该分支在删除之前已合并到另一个分支中，那么当第一个分支被删除时，仍然可以从另一个分支访问所有提交。它们仍然保持原样。
如果分支被删除而没有合并到另一个分支中，那么该分支中的提交（直到从仍然可访问的提交中分叉出来的点）将不再可见。
提交仍将保留在存储库中，并且可以在删除后立即恢复它们，但最终它们将被垃圾收集。
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.
在 Git 中，分支只是指向提交的有向无环图 (DAG) 中的提交的指针（引用）。这意味着删除分支只会删除对提交的引用，这可能会使 DAG 中的某些提交无法访问，从而不可见。但是，已删除分支上的所有提交仍将位于存储库中，至少在无法访问的提交被修剪之前（例如使用 git gc ）。
请注意，如果 gitbranch -d 无法确定删除分支不会留下无法访问的提交，则它会拒绝删除分支。如果分支可能会留下无法访问的提交，您需要使用更强大的 gitbranch -D 来强制删除该分支。
另请注意，无法访问的提交（如果存在）只是已删除分支的最后一个提示与合并到另一个现有分支的提交、任何标记的提交或分支点之间的提交；以较晚者为准。例如在以下情况下：
----O----*----*----/M----* <-- master <-- HEAD \ / \--.----.--/--x---y <-- deleted branch删除分支后，只有提交“x”和“y”将变得不可访问。
如果您在
gc.reflogExpire期限内（默认 90 天）对已删除的分支进行操作，您将在 HEAD reflog 中记录已删除分支的最后提示（请参阅git reflog show HEAD 或 git log --oneline --walk-reflogs HEAD）。您应该能够使用 HEAD reflog 来恢复已删除的指针。另请注意，在这种情况下，仅已删除分支中的无法访问的提交将在gc.reflogExpireUnreachable期限内（默认为 30 天）免受修剪（删除）。如果你在 HEAD 的 reflog 中找不到刚刚删除的分支的提示，你可以尝试使用 git fsck 来查找“unreachable commit”，并检查这些（通过
>git show或git log) 来查找已删除分支的提示。无论您如何找到已删除分支的提示，您都可以撤消删除，或者使用 Note 重新创建刚刚删除的分支，
但是分支的引用日志将会丢失。
git-resurrect.sh 脚本 < code>contrib/ 有助于查找具有给定名称的分支提示的痕迹并复活（取消删除）它。
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 -dwould refuse to delete a branch if it cannot be sure that deleting it wouldn't leave unreachable commits. You need to use the strongergit branch -Dto 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 branchonly commits 'x' and 'y' would become unreachable after deleting the branch.
If you operated on a deleted branch within the
gc.reflogExpireperiod, default 90 days, you would have the last tip of a deleted branch recorded in HEAD reflog (seegit reflog show HEAD, orgit 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 thegc.reflogExpireUnreachableperiod, 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 fsckto find "unreachable commit <sha1>", and examine those (viagit show <sha1>orgit 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
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.如果您担心意外删除分支并且不再拥有存储库的本地副本，可以使用 Gerrit 等企业 Git 服务器的扩展，它将检测历史记录重写和分支删除，并将它们备份到特殊的引用下，以便它们如果需要可以恢复，并且不会被垃圾收集修剪。如果出于法律原因需要，Gerrit 管理员仍然可以删除选定的提交。
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.