コンテンツマネージャーとしてgit lfs

Question

git lfsをコンテンツマネージャーとして使用するシナリオがあります。 GCは、ブランチ・イメージの変更されたすべてのファイルが削除されます必要がありますが正しく実行されている場合、そのすべての後

          master images combined 
init lfs          (1) 
create images branch         (2) 
add 2 files           (3) 
edit 2 files           (4) 
edit 2 files           (5) 
edit 2 files           (6) 
create branch from master          (7) 
combine images to combines as 1 commit       (8) 
delete images branch         - 
merge combined to master      (10) 

：

私の計画は、そのようなテスト何かをすることでした。

正しいですか？ lfsのGCはすべての参照されていないイメージを削除する必要があるので、ブランチは削除されているので、コミットも削除する必要があります。

P.S.プロジェクトの歴史は、私はプロジェクトを削除し、上記のすべての

UPDATE

後にのみ2コミットを示し、GCの後にスペースが削除されました実行します。

Answer 1

はい、中間ファイルは任意のGitの参照によって参照されていないとなった場合 - （ローカルまたはリモート）ブランチであるか、タグ - あなたのGitの歴史の中で、その後git-lfsファイルは削除対象になります。

しかし、いくつかの操作の後で自動的にGCが実行されるのとは異なり、git-lfsはこれを自動的に行いません（少なくとも、私が知っていた時間は少なかったのですが、少し時間がかかりました）。代わりにgit lfs pruneを実行すると、参照されていないファイルは削除されます。

しかし、git lfs pruneは一般的にディスクスペースを回復するように設計されているため、gitリポジトリで参照されているファイルのローカルバージョンは削除できますが、最近のブランチでは削除されますリモートはローカルに存在するだけではありません）。詳細については、git lfs prune --helpを参照してください。

HTH

Answer 2

コミットのため

おそらくgitlab-CEは削除されませんでしたすべての参照、もう一度例を試してみたが、私は、 `gitのLFSがローカルprune`使用してクリアした