ブランチの削除 - .git/refs/headsのファイルを編集するのに安全ですか？

Question

私たちのチームが使用するカスタムGitツールは、新しい機能/バグが作業されるたびにブランチを作成します。

変更が近づいていない場合、リモートブランチは別のツールを使用して変更され、ブランチのローカルコピーは同期しないままになります。

多くの場合、開発者のローカルリポジトリに残っている古いブランチをすべてクリーンアップする方法があります。 git branch -D branchnameを入力すると、このような古いブランチが数多くある場合には、面倒な作業になる可能性があるので、ショートカットが必要です。

私が出していたアドバイスのいくつかは、.git/refs/headsフォルダからファイルを削除することでした。

一つのマニュアルトリックすぐにバッチで枝を削除するか.git/refs/heads folderから ファイルを削除することです。

は、ここで私が送り出す全文です。 がブランチに対応するファイル名が表示されます。ブランチは、 をファイルの内容にするshaへのポインタに過ぎないので、ファイルを削除するとブランチが削除されます。 ポインタが実際にコミットされていないことを指摘します。 ポインタが指し示されたことを意味します。

このアドバイスはは安全なようだが、私はこのアプローチが失敗したり、仕事を失ったりする可能性があります状況があることを妄想しています。

masterファイルを削除するなどの間違いをしたユーザー以外は、この安全なアドバイスはありますか？

EDIT：この質問は、ローカルブランチが古いかそうでない場合が多い--mergedが決定するのに十分ではないだろう、なぜならによる当社の社内ツールの性質上this questionは異なっています。また、私たちは一羽の急降下で枝を削除したくないです...まだ活動していない枝を削除しないように、各枝の手動チェックが必要です。

Answer 1

一つの落とし穴は、参照は、「パック」されている場合は、過去に、様々なブランチ名と対応するハッシュIDが.git/packed-refsはなくまたは.git/refs/heads/にあるのほかになるということです。

名が両方の場所に表示された場合は、.git/refs/heads/Bから支店名Bを削除すると、単に古いパックの参照を明らかにする。 .git/packed-refsにしか存在しない場合、削除する別個のファイルはありません。

これも古くなったreflogを残します。これは一時的に機能（the comment by Chrisのような）ですが、reflogには@{0}という値は含まれず、@{1}以上の値しか含まれていないことに注意してください。

Gitの今後のバージョンでは、大文字と小文字を区別するWindowsおよびMacOSファイルシステムでは間違っているため、ブランチ名ごとの1つのトリックを完全に破棄することが強く疑われます。git branch -Dまたはgit update-ref -dを使用することは、明らかに優れている/より安全に/将来的に証明されています（update-refには完全な参照名のスペルが必要です）。