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し--unreachableて--danglingもエラーは発生しません。私もやってみ--lost-foundました。

ただし、git fsck <hash of commit #3>5 つの未解決コミットと多数の未解決タグが生成されます。

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...

2 つの質問があります。

  1. 何がこの状況を引き起こした可能性がありますか (ブランチ#1が切り離されたなど)?

  2. 他のリポジトリに同様の問題があるかどうかを検出するにはどうすればよいですか? (などの切り離されたコミットのハッシュを知る必要はありません#3)

ブランチから切り離されたコミット

更新：

質問 (1) に対する答えが見つかりました。この状況は、ブランチの古いスナップショットを持っていた開発者による、中央のベア リポジトリへの強制プッシュによって引き起こされました。

4

2 に答える 2

2
  1. あなたが言ったように; これは使用によって引き起こされますgit push --force
  2. すべてのコミットはタグで達成できるため。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です...

于 2016-01-05T07:24:59.120 に答える