8

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

其中，#1指向曾经是分支的线路，1.7.6.14.X并#2指向同一分支的当前状态。

引用的提交#3和该行上的前 8 个提交以前附加到 branch 1.7.6.14.X。然后另一个开发人员应该检查了同一个分支并做了#4. 此#4提交已从分支中删除了前 9 个提交，1.7.6.14.X并使它们悬空。
结果，分支1.7.6.14.X现在从原始分支点开始，而不是仅仅从 commit 扩展#3。

运行git fsck, etc 不会给出任何错误--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）的答案。这种情况是由拥有旧分支快照的开发人员强制推送到中央裸仓库引起的。

4

2 回答 2

5

这是一个帖子Linus Torvalds：

Linus 描述了什么是悬空对象，它们何时被抛在后面，以及如何在 gitk 中查看它们与分支头的关系

是什么导致了这种情况（即分支#1 分离）？

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

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

如何检测其他存储库中是否存在类似问题？
（不必知道分离提交的哈希值，例如#3）

git fsck --full

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

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

悬垂的斑点

使其进入暂存区域/索引的更改（一旦您执行git addgit 计算 SHA-1 并开始跟踪内容）但从未提交。

悬空提交

不直接或通过其任何祖先链接到任何分支或标签的提交。

于 2016-01-04T00:53:19.180 回答
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...

于 2016-01-05T07:24:59.120 回答