を使用して、ローカルリポジトリで到達不能でぶら下がっているコミットをいくつか削除しました
git fsck --unreachable --dangling --no-reflogs
git reflog expire --expire=now --all
git gc --prune=now
しかし、削除されたコミットはオリジン (正確には GitHub) で引き続き利用できることがわかりました。
試しgit push --forceましたが、変更がオリジンに同期されません。変更をオリジンに強制的に同期するにはどうすればよいですか (到達不能/ぶら下がっているコミットもリモートから削除されます)。
これは、答えのない同様の質問です。
リモートがクライアントからのデータを保存する方法を指示することはできません。
まず、ローカル リポジトリがリモート リポジトリと同じではないことを理解することから始めるべきだと思います。 質問をしているので、すでに知っているローカルリポジトリgit fsckで操作します。git gc
次に、Git はオブジェクトを転送することによって機能します。ここでの秘訣は、ネットワーク経由で到達可能なオブジェクトについてのみ話すことです。つまり、参照 (ブランチまたはタグ) からオブジェクトへのパスが何らかの形で履歴に存在する必要があります。参照されているオブジェクトに到達できない場合、オブジェクト データベースにある場合でも、Git はクライアントへの転送を拒否します。これの裏側は、参照の変更または更新を伴わないローカルで行うことはすべて、ローカルとリモートのリポジトリ間で通信できないことです。「ローカル オブジェクト データベースのレイアウトをリモートに同期する」とは言えません。「ローカルとリモートの間で到達可能なオブジェクトを同じにする」としか言えません。
最後に、物事が GitHub でどのように表現されるか、およびオブジェクトが最終的にプルーニングされるかどうかは、完全に GitHub 次第です。Zach Holmanが、舞台裏で起こっていることのいくつかについて講演しました。バックグラウンドで何かを実行して、ある時点でぶら下がっているオブジェクトを整理していると思いますが、リモート アクセスの観点からは、実際には問題ではありません。人々は参照されていないオブジェクトにアクセスできません。残された唯一の問題はサイズです。過去にリポジトリをトリミングしてサイズを縮小したため、彼らがある種の剪定を行っていることはわかっています (これは、API 呼び出しを使用してサイズ メンバーを調べることで確認できます。例としてこれを試すことができます: https:/ /api.github.com/repos/jszakmeister/vimfiles )。
大きすぎるオブジェクトをチェックインしたためにリポジトリのサイズを縮小することが目的の場合は、GitHub のヘルプ セクションから機密データの削除ページを参照してください。永久に削除したい大きなファイルにも同様に適用されます (単純にコミットによって削除しても、履歴から完全に削除されるわけではありません)。
ぶら下がっているオブジェクトを圧縮して削除することでリポジトリのサイズを縮小することが目標である場合、GitHub はすでに独自のことを行っており、それがどのように行われるかを実際に制御することはできません。ただし、彼らはそれを小さく、速く、効率的に保つために多大な努力を払っています。