Question

最后是从SourceTree分支树视图中提取的截图（截图中间有一个间隙）

在此，#1指向曾经是分支1.7.6.14.X的行，#2指向同一分支的当前状态。

#3引用的提交以及该行前面的8次提交以前已附加到分支1.7.6.14.X。然后另一个开发人员据说检查了同一个分支并完成了#4指向的修复。这个#4提交已从分支1.7.6.14.X中删除了前9个提交，并将它们悬空。
因此，分支1.7.6.14.X现在从原始分支点开始，而不是仅从提交#3扩展。

使用git fsck，--unreachable等运行--dangling并不会产生任何错误。我也试过--lost-found。

但是，git fsck <hash of commit #3>会产生五个悬空提交和一大堆悬空标记：

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3148/3148), done.
dangling commit ec213...
dangling commit ab82a...
dangling commit 7d262...
dangling commit a6f06...
dangling commit 6674a...

我有两个问题：

可能导致这种情况的原因（即分支#1分离了吗？）
如何检测其他存储库中是否存在类似问题？（不必须知道#3等分离提交的哈希值）

更新：

我们找到了问题（1）的答案。这种情况是由一个开发人员用力推动中央裸仓库，这个开发人员有一个较旧的分支快照。

Answer 1

Here是帖子 Linus Torvalds ：

Linus describes what dangling objects are, when they are left behind, and how to view their relationship with branch heads in gitk

可能导致这种情况的原因（即分支＃1分离）？

悬空数据是存储在git存储库中但无法访问的数据这意味着您拥有（添加或提交）您的存储库中无法访问的内容（没有提交或分支具有或指向此内容）

所以答案是肯定的，分支＃1上的所有提交都不能从分支＃1旁边的任何提交中访问。

如何检测其他存储库中是否存在类似问题？（无需知道诸如＃3之类的分离提交的哈希值）

git fsck --full

此命令将检查所有存储库中的悬空内容

您的存储库中可能有两种悬空内容：

悬空blob

进入临时区域/索引的更改（一旦你{g}计算了SHA-1并开始跟踪内容{}}，但从未提交过。

悬空提交

未直接或由其任何优先级链接到任何分支或标记的提交。

Answer 2

正如你所说;这是由使用git push --force
由于所有提交都可以通过标记获得; git永远不会说嘿嘿，因为他们不。它们永远不会丢失或清理，因为标签指的是它们。

至于如何找到这些（因为没有更好的词）悬空提交;我没有找到任何纯粹的git，但我想出了一个允许检测它们的小脚本。可能有一种方法可以使这个性能更高，但是可以解决这个问题：

for sha in $(git log --all --pretty=format:"%H")
do
    if [ -z "$(git branch --contains $sha)" ]
    then
        echo "commit not on a branch: $sha"
    fi
done

注意我知道测试-z ""不是很干净，但git branch的返回值始终为0 ......

git：这些悬挂提交吗？

2 个答案:

悬空blob

悬空提交