GitHub で Pull Request マージ時に Issue を自動クローズするかどうか選べるようになりました
2025.04.25こんにちは、製造ビジネステクノロジー部の若槻です。
GitHub で Pull Request をマージした際に、リンクされた Issue を自動的にクローズするかどうかを選択できるようになるアップデートがありました。
背景
これまで GitHub では、Issue にリンクされた Pull Request (PR) がマージされると、自動的にその Issue がクローズされる仕様でした。しかし、多くのチームにとって PR のマージは作業の完了を意味するわけではありません。QA、検証、フォローアップなど、Issue が本当に解決されるまでには追加のステップが必要な場合があります。
この新機能により、PR マージ時に Issue を自動クローズするかどうかをリポジトリ単位で設定できるようになりました。
やってみた
実際に設定方法と動作を確認してみます。
設定の変更
リポジトリの Settings から General → Issues セクションに移動すると、新しい設定項目が追加されています。
「After merging a pull request, linked issues can be closed automatically.」という設定項目があり、デフォルトではオンになっています（従来の動作を維持するため）。
今回はこの設定をオフにして、PR マージ時に Issue が自動クローズされないようにしてみます。
動作確認
-
まず、リポジトリの設定画面で「After merging a pull request, linked issues can be closed automatically.」のチェックを外して設定を保存します。
-
テスト用の Issue #379 を作成しました。
-
この Issue に対応する変更を行い、PR を作成します。PR の説明文に「Fixes #379」と記載して Issue とリンクさせました。
-
PR をマージします。
-
マージ後、Issue #379 の状態を確認すると、リンクされている PR がクローズされているにも関わらず、自動クローズされずに Open のままになっています。
比較のため設定を戻してみる
設定を元に戻して（自動クローズを有効にして）同じ手順を試してみました。
- 新たに Issue #43 を作成し、それに対応する PR を作成してリンク
- PR をマージすると、今度は Issue #43 が自動的にクローズされました
これにより、設定の違いによる動作の違いが確認できました。
使い方の例
設定をオフにする場合のユースケース
- QA プロセスがあり、コードマージ後に別途テストが必要な場合
- デプロイが別のプロセスで行われ、実際にユーザーが使えるようになるまで Issue をオープンにしておきたい場合
- 複数の PR で対応する大きな Issue があり、すべての PR がマージされるまで Issue をクローズしたくない場合
設定をオンにする場合のユースケース（デフォルト）
- シンプルな開発フローで、PR マージ = Issue 解決の場合
- 小規模チームや個人プロジェクトで追加のプロセスがない場合
注意点
- この設定はリポジトリ単位で適用されます
- リポジトリの管理者（admin）やメンテナー（maintainer）のみが変更可能です
- デフォルトでは従来通り自動クローズが有効になっています
- 設定を変更しても、過去にマージされた PR によってクローズされた Issue は再オープンされません
おわりに
GitHub の PR マージ時に Issue を自動クローズするかどうかを選択できるようになったことで、より柔軟なワークフローが実現できるようになりました。チームの開発プロセスに合わせて適切な設定を選ぶことで、Issue 管理がより効率的になるでしょう。
この機能は 2025 年 4 月 23 日にリリースされたばかりです。皆さんのチームのワークフローに合わせて活用してみてください。
以上
