によって提示された情報の中に、git help fetchこの小さなアイテムがあります:
-p, --prune
After fetching, remove any remote-tracking branches which no longer exist on the remote.
それで、おそらく、git fetch -pあなたが探しているのは何ですか?
編集:わかりました、事実の3年後もこの回答についてまだ議論している人のために、なぜ私がこの回答を提示したのかについてもう少し情報があります...
まず、OPは、「リモートブランチから作成されたローカルブランチも削除します(リモートには存在しなくなります)」と述べています。これはで明確に可能ではありませんgit。ここに例があります。
中央サーバーにリポジトリがあり、それにとと呼ばれる2つのブランチがあるとAしBます。そのリポジトリをローカルシステムにクローンすると、クローンにはorigin/Aandと呼ばれるローカル参照(実際のブランチではない)が含まれorigin/Bます。今、私が次のことをするとしましょう:
git checkout -b A origin/A
git checkout -b Z origin/B
git checkout -b C <some hash>
ここで関連する事実は、なんらかの理由で、ローカルリポジトリにオリジンとは異なる名前のブランチを作成することを選択したことと、オリジンリポジトリに(まだ)存在しないローカルブランチがあることです。
ここで、リモートリポジトリのAとBブランチの両方を削除し、ローカルリポジトリ(git fetchなんらかの形式)を更新するorigin/Aとorigin/Bします。これにより、ローカル参照が消えて消えます。さて、私の地元のレポは、まだ3つの分岐がありA、ZとC。これらのいずれにも、リモートリポジトリに対応するブランチはありません。そのうちの2つは「...のリモートブランチから作成された」ものですがB、元々呼び出されていたブランチがあったことを知っていても、それZがB、それはおそらく正当な理由で、プロセス中に名前が変更されたためです。したがって、実際には、ブランチのオリジンメタデータを記録する外部プロセスがないか、履歴を知っている人間がいない場合、3つのブランチのどれがOPが削除の対象となっているかを特定することはできません。git自動的に維持されない外部情報がなければ、git fetch -p取得できるのはほぼ同じです。OPが要求したことを文字どおりに試行する自動方法では、分岐が多すぎるか、OPがそうでない場合に欠落するリスクがあります。削除したい。
他のシナリオもあります。たとえば、origin/A3つの異なるブランチを作成して、何かへの3つの異なるアプローチをテストしてから、離れる場合などorigin/Aです。現在、3つのブランチがありますが、明らかに名前ごとに一致するわけではありませんが、それらはから作成されたorigin/Aため、OPの質問を文字どおり解釈するには、3つすべてを削除する必要があります。しかし、それらを一致させる信頼できる方法を見つけることができれば、それは望ましくないかもしれません...