git branch -d mybranchローカル ブランチが完全にマージされていない場合、Git はデフォルトでローカル ブランチの削除を ( 経由で) 拒否します。
ただし、を介してリモート ブランチを削除するとgit push origin --delete mybranch、ブランチが完全にマージされていない場合、警告はまったく表示されません。
これはかなり危険に思えます: 私が最後にブランチを取得してから、他の誰かがブランチに更新をプッシュした可能性があるため、マージされていないブランチを誤って削除する可能性は、ローカル ブランチの場合よりもリモート ブランチの方が高いようです。
では、リモートのマージされていないブランチを削除しても、git が警告しないのはなぜですか? また、削除を警告または拒否する方法はありますか?
注:理想的にはgit pull、ブランチを削除する前にブランチを削除し、完全にマージされていることを確認する必要があることを認識しています。ただ、ミスは誰にでもありますし、セーフティーネットはつけておきたいですね。
ただし、git push origin --delete mybranch を介してリモート ブランチを削除すると、ブランチが完全にマージされていない場合、警告はまったく表示されません。
私の答えは「何と合併したのですか？」です。リモートのHEAD？支店master？他の何か？Git ref マッチングは多かれ少なかれ無限に構成可能です。複数のリモートを構成できます。上流の追跡ブランチは、ローカルのカウンターパートと同じ名前である必要はありません。方法がわかれば、複数のアップストリーム追跡ブランチを構成することもできます(これは「タコ」プルと呼ばれ、それを可能にする磁器コマンドはありません)。
git branch -dブランチがそのアップストリーム ブランチ (リモート リポジトリには存在しないもの) とマージされていないことを確認し、アップストリームが存在しない場合はHEAD. リモートリポジトリの対応するチェックは、それほど明白ではありません。
以下のkanのコメントによると、リモートブランチを削除するとダングリングコミットが生成されたかどうかも確認できます（より強力なgit branch -d. このタイプの保護もないと思いますし、数十または数百のブランチを持つリモートで検証するのは簡単なことではないかもしれません.
あなたができる最善の方法は、削除を完全に防ぐことですreceive.denyDeletes。