Gitのブランチを削除する前に｜マージ済み判定と共有先の確認

Gitのブランチを削除する前には、どこへ統合されたことを確認するのかを決めます。「マージ済み」という表示だけでは、自分が想定した統合先へ変更が残っているか分かりません。

この記事ではローカル削除を中心に、確認する順番を整理します。コマンドは説明用の未実行例で、共有ブランチの削除は共同作業者や管理ルールの確認が必要です。

削除対象と統合先を一組で確認する

仮に作業ブランチがtopic/report、残したい統合先がmainだとします。先に変更一覧と各ブランチの参照先を確認します。

git status
git branch -vv
git log --oneline main..topic/report

最後の例は、topic/reportから到達でき、mainから到達できないコミットを確認するものです。Git公式log仕様

結果が空でない場合は、残る変更の目的を確認します。また、squashなどで別コミットとして取り込まれた変更は、コミットの到達関係だけで同じ内容か判定できません。レビュー記録と実際の差分を併せて確認しましょう。

git branch --merged mainは、指定したコミットから到達できる先端を持つブランチを表示します。一方、削除の-dは追跡先があればその追跡先、なければHEADへの統合を確認します。Git公式branch仕様

この違いから、-dで消せることと、目的のmainへの統合確認は同じではありません。ブランチの追跡先と、自分が変更を残したい先を照合します。

目的の統合先への反映と作業終了を確認した後、対象以外のブランチへ切り替えて削除する例です。

git switch main
git branch -d topic/report

削除を拒否されたら理由を確認します。未統合の変更なのか、別のworktreeで使われているのかなど、現在の状態を調べる場面です。拒否を消すためだけに強制削除へ進まないようにします。

ブランチ名の削除は、履歴を残す名前の一つを失う操作です。消した後で探し直すことを前提にせず、必要な変更が保持されていることを先に確かめます。

手元のブランチ削除と、リモート参照の削除は別です。git pushにはリモート参照の削除操作もありますが、共有中の作業や保護規則を確認してから扱います。

ブランチ数を減らすことより、必要な変更がどこへ残ったか説明できることが重要です。コードレビューの観点と合わせ、対象・統合先・未統合変更を確認してから整理しましょう。