Git：什么是悬空提交/blob，它们来自哪里？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18514659/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git: what is a dangling commit/blob and where do they come from?
提问by doub1eHyman
I'm looking for the basic info on dangling commits & blobs.
我正在寻找有关悬空提交和 blob 的基本信息。
My repo seems fine. But I ran git fsckfor the first time to see what it did and I have a long list of 'dangling blobs' and a single 'dangling commit'.
我的回购似乎很好。但是我git fsck第一次跑去看看它做了什么，我有一长串“悬空的斑点”和一个“悬空的提交”。
What are these things? Where did they come from? Do they indicate anything unusual (good or bad) about the state of my repo?
这些是什么？哪儿来的？它们是否表明我的回购状态有任何异常（好或坏）？
采纳答案by vgoff
During the course of working with your git repository, you may end up backing out of operations, and making other moves that cause intermediary blobs, and even some things that git does for you to help avoid loss of information.
在使用 git 存储库的过程中，您最终可能会退出操作，并进行其他导致中间 blob 的操作，甚至 git 为您做的一些事情来帮助您避免信息丢失。
Eventually (conditionally, according to the git gc man page) it will perform garbage collection and clean these things up. You can also force it by invoking the garbage collection process, git gc.
最终（有条件地，根据git gc 手册页）它将执行垃圾收集并清理这些东西。您还可以通过调用垃圾收集过程来强制它git gc。
For more information about this, see Maintenance and Data Recoveron the git-scm site.
有关这方面的更多信息，请参阅git-scm 站点上的维护和数据恢复。
A manual run of GC will by default leave 2 weeks prior to the runtime of this command of a safety net. It is in fact encouraged to run the GC occasionally to help ensure performant use of your git repository. Like anything, though, you should understand what it is doing before destroying those things that may be important to you.
默认情况下，手动运行 GC 将在安全网的此命令运行前 2 周。实际上鼓励偶尔运行 GC 以帮助确保您的 git 存储库的高效使用。但是，像任何事情一样，在销毁那些对您来说可能很重要的东西之前，您应该了解它在做什么。
回答by Elijah Lynn
Dangling blob= A change that made it to the staging area/index but never got committed. One thing that is amazing with git is that once it gets added to the staging area, you can always get it back because these blobs behave like commits in that they have a hash too!!
Dangling blob= 更改到暂存区/索引但从未提交。git 令人惊奇的一件事是，一旦它被添加到暂存区，你就可以随时取回它，因为这些 blob 的行为就像提交一样，因为它们也有一个哈希值！！
Dangling commit= A commit that isn't directly linked to by any child commit, branch, tag or other reference. You can get these back too!
悬空提交= 未由任何子提交、分支、标签或其他引用直接链接的提交。你也可以拿回这些！
回答by qxo
HOWTO remove all dangling commits from your git repository from http://www.tekkie.ro/news/howto-remove-all-dangling-commits-from-your-git-repository/
HOWTO 从http://www.tekkie.ro/news/howto-remove-all-dangling-commits-from-your-git-repository/ 中删除所有悬空提交
git reflog expire --expire=now --all
git gc --prune=now
Make sure you really want to remove them, as you might decide you need them after all.
确保您真的想删除它们，因为您可能最终决定需要它们。
回答by MasterJoe2
A dangling commit is a commit which is not associated with reference, i.e there is no way to reach it.
悬空提交是与引用无关的提交，即无法访问它。
For example, consider the diagram below. Suppose we delete the branch featureX without merging its changes, then commit D will become a dangling commit because there is no reference associated with it. Had it been merged into master, then HEAD and master references would have pointed to commit D and it would not be dangling anymore, even if we deleted featureX. Read the note after the diagram to understand this better.
例如，考虑下图。假设我们删除分支 featureX 而不合并其更改，那么提交 D 将成为悬空提交，因为没有与之关联的引用。如果它被合并到 master 中，那么 HEAD 和 master 引用将指向提交 D，即使我们删除了 featureX，它也不会再悬空了。阅读图表后的注释以更好地理解这一点。
Git automatically garbage collects (i.e disposes) dangling commits. We can use the git reflogto recover a branch (of dangling commits) which was deleted without merging it. We can recover deleted commits only if it is present in local object store. If it was garbage collected, then we can't recover it.
Git 会自动垃圾收集（即处理）悬空提交。我们可以使用git reflog来恢复（悬空提交的）分支，该分支在没有合并的情况下被删除。只有当它存在于本地对象存储中时，我们才能恢复已删除的提交。如果它被垃圾收集，那么我们就无法恢复它。
NOTEthat a branch name i.e. branch label is actually a reference to the latest commit on a branch i.e the tip of the branch. In the diagram above, featureX, master and HEAD are just references to specific commits. featureX and master labels refer to latest commits on their respective branches. HEAD generally refers to the tip of the currently checked out branch (master in this case). If you checkout an older commit on your current branch, then HEAD will be in a detached state, i.e. it will point to the older commit instead of the latest one. Also note that HEAD is called a symbolic reference because it actually points to the current branch label and any branch label always points to the tip of the branch. So, under normal circumstances, HEAD indirectly points to the latest commit.
请注意，分支名称即分支标签实际上是对分支上最新提交的引用，即分支的尖端。在上图中，featureX、master 和 HEAD 只是对特定提交的引用。featureX 和 master 标签是指它们各自分支上的最新提交。HEAD 一般指的是当前检出的分支（在这种情况下是 master）的尖端。如果您在当前分支上签出较旧的提交，则 HEAD 将处于分离状态，即它将指向较旧的提交而不是最新的提交。还要注意 HEAD 被称为符号引用，因为它实际上指向当前分支标签，并且任何分支标签总是指向分支的尖端。所以，一般情况下，HEAD 会间接指向最新的提交。
As an aside, note that Git represents its commit graph/history as a directed acyclic graph. Each commit has a reference to it parent. Hence, the arrows in a commit diagram point from child commit to parent commit. We need a reference to the latest child commit in order to reach the older commits on a branch.
顺便说一句，请注意 Git 将其提交图/历史表示为有向无环图。每个提交都有一个对它的父级的引用。因此，提交图中的箭头从子提交指向父提交。我们需要引用最新的子提交才能到达分支上的旧提交。
PS- The above diagram and understanding was obtained from this free course. Even though the course is quite old, the knowledge is still relevant.
PS-上图和理解是从这个免费课程中获得的。尽管课程很老，但知识仍然相关。
