git:这些悬挂提交吗？

Question

最后给出的是从SourceTree分支树视图中提取的屏幕截图(屏幕截图中间有一个间隙)

在那里,#1指向曾经是分支的行1.7.6.14.X并#2指向同一分支的当前状态.

由#3该行引用的提交和之前的8次提交之前已附加到分支1.7.6.14.X.然后另一个开发人员据说检查了同一个分支并完成了修复指向#4.这个#4提交已经从分支中删除了前9个提交1.7.6.14.X并让它们悬空.
因此,分支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. 什么可能导致这种情况(即分支#1分离)？

2. 如何检测其他存储库中是否存在类似问题？(无需知道分离提交的哈希值#3)

更新:

我们找到了问题(1)的答案.这种情况是由一个拥有旧分支快照的开发人员向中心裸仓库推动的.

Answer 1

这是一篇帖子Linus Torvalds:

Linus描述了悬挂物体是什么,何时被遗忘,以及如何在gitk中查看它们与分支头的关系

什么可能导致这种情况(即分支#1分离)？

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

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

如何检测其他存储库中是否存在类似问题？
(无需知道#3等分离提交的哈希值)

git fsck --full

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

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

晃来晃去的斑点

进入临时区域/索引的更改(一旦你执行git addgit计算SHA-1并开始跟踪内容)但从未提交.

悬空提交

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

Answer 2

1. 如你所说; 这是由于使用引起的git push --force
2. 由于您的所有提交都可以通过标签实现；git 永远不会说 hey are dangling，因为它们不是。它们永远不会丢失或清理，因为有标签引用它们。

至于如何找到这些（因为没有更好的词）悬空提交；我没有找到任何纯粹的 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...