GitHub Actionsで作業ブランチ（feature）を自動削除する方法

システム開発において、GitHubを活用して複数人での作業を効率化している現場は多くあります。
特に作業ブランチ（featureブランチ）を使った運用は、開発の分担とコードの整理に大きく役立ちます。

しかし、マージ後にfeatureブランチが削除されずに残り続けると、リポジトリが煩雑化し、管理が難しくなるという問題が生じます。本記事では、mainブランチやバージョンブランチ（v1.0.0など）を保護しつつfeatureブランチのみを自動で削除する具体的な手順を紹介します。

前提と目的

• main：開発の中心となるブランチ（削除しない）
• v*：リリース済みのバージョン管理用ブランチ（削除しない）
• feature/*：個別の作業に使う一時的なブランチ（マージ後に自動削除）

GitHubの無料プランではブランチ保護の細かい設定は制限がありますが、GitHub Actionsを使うことで同等の運用を実現できます。

GitHub Actionsでの自動削除の仕組み

GitHub Actionsは、リポジトリの中にある.github/workflows/フォルダに定義ファイル（YAML形式）を置くことで、様々な自動処理を実行できます。
ここではプルリクエストがマージされたタイミングでfeatureブランチのみ削除という処理を設定します。

実装例（安全対策済み）

以下に紹介する内容は、削除対象のブランチが必ずfeatureに限定されており、mainやvブランチが削除されることはありません。

ポイントの解説

pull_request: closed

プルリクエストがクローズされたときにワークフローが実行されるよう設定しています。
マージ後のブランチ削除に適したトリガーです。

if: merged == true

単なるクローズではなく、マージされた場合のみ実行されるように制限しています。
これにより、マージ前に取り下げたプルリクエストのブランチが誤って削除されることを防ぎます。

startsWith(‘feature/’)

作業ブランチのみ削除する条件です。
mainやv1.0.0といったブランチには該当しないため、安全が担保されています。

git push origin –delete

このコマンドにより、リモートのfeatureブランチが削除されます。
ローカルのブランチには影響しません。

注意点

• ブランチ名に日本語や記号が含まれるとエラーになる可能性があるため、英数字やハイフンなどの使用を推奨します。
• ワークフローの変更後は、必ずテスト用のリポジトリで検証してください。
• 保護すべきブランチの名前が変わる可能性がある場合は、startsWith() の条件もあわせて調整してください。

よくある質問

マージせずにクローズした場合でも削除されますか？

削除されません。merged == true が条件なので、マージされた場合のみ削除されます。

削除されるのはローカルブランチですか？

リモートブランチのみが削除対象です。ローカルには影響しません。

main や v1.0.0 などを間違って削除しないか心配です

startsWith('feature/') によって、それ以外のブランチは削除対象外になります。
保護対象のブランチは完全に除外されています。

まとめ

featureブランチの自動削除は、チーム開発におけるリポジトリの整理と品質維持に大きく貢献します。
無料プランでも、GitHub Actionsを活用することで安全かつ自動的な運用が可能です。

本記事で紹介した手法を導入することで、作業の効率化と人的ミスの予防につながります。
ぜひあなたの開発現場にも取り入れてみてください！