Pull RequestのUpdate BranchボタンをGitHub Actionsで自動化したら便利だった話

こんにちは、ハコベル開発チームの坂東です。

チーム開発で Pull Request を作成して作業していると、base ブランチが古いまま開発を続けてしまい、後で作業が巻き戻ってしまったという経験はありませんか？

例えば、他のメンバーが先にマージした変更と競合したり、既に修正済みのバグを再度修正してしまったり。特に、feature ブランチから派生したブランチなど、ブランチがネストしている場合にこの問題が起きやすいです。

基本的に、作業中は常に最新の base ブランチの変更を取り込むことが求められますが、手動で git pull origin main や git merge main を実行するのは面倒だし、忘れがちですよね。

実は、この課題を解決するために GitHub には "Update branch" という便利な機能があります。ただ、この機能の存在を知らない開発者も意外と多いんです。

今回は、この Update branch 機能を GitHub Actions で自動化してみたら、かなり便利だったので紹介します。

そもそも Update Branch ボタンって何？

Pull Request を作成した後、base ブランチ（main や develop）に新しいコミットが追加されると、GitHub の Pull Request 画面に "Update branch" ボタンが表示されます。

このボタンをクリックすると、base ブランチの最新の変更を feature ブランチにマージして、Pull Request を最新の状態に更新できます。

Update Branch 機能を使うための設定

ただし、この機能を使うにはリポジトリの設定が必要です。

リポジトリの Settings > General > Pull Requests で、"Always suggest updating pull request branches" にチェックを入れてください。

この設定をしておくと、Pull Request が古くなったときに Update Branch ボタンが表示されます。

参考：GitHub の Update branch を使おう

設定してないリポジトリだと、そもそも Update Branch ボタンが表示されません。

ただ、この作業を毎回手動でやるのは正直面倒です。Pull Request の数が多いと作業が煩雑になるし、更新し忘れて古い状態のまま放置されがち。しかも開発者によっては Update Branch の存在自体知らないこともあります。

GitHub Actions で自動化してみた

そこで、GitHub Actions を使って Pull Request のブランチ更新を自動化してみました。

以下のワークフローファイルを .github/workflows/autoupdate-prs.yml として配置しています：

name: Auto-update Pull Requests

on:
  pull_request:
    types: [opened, synchronize, labeled, unlabeled]

jobs:
  autoupdate-prs:
    runs-on: ubuntu-latest
    steps:
      - name: Auto-update Pull Request Branches
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { owner, repo } = context.repo;

            // このワークフローを発火させたPRのみを対象に自動更新
            const pr = context.payload.pull_request;
            if (!pr) {
              console.log('Not triggered by a pull_request event.');
              return;
            }
            try {
              await github.rest.pulls.updateBranch({
                owner,
                repo,
                pull_number: pr.number,
                expected_head_sha: pr.head.sha, // オプティミスティックロック用
              });
              console.log(`Successfully updated PR #${pr.number} (${pr.head.ref}).`);
            } catch (error) {
              if (error.status === 422 && error.response.data.message.includes('Conflicts')) {
                console.warn(`PR #${pr.number} (${pr.head.ref}) has conflicts. Manual intervention needed.`);
              } else {
                console.error(`Failed to update PR #${pr.number} (${pr.head.ref}):`, error);
              }
            }

ワークフローの仕組み

このワークフローの動作を詳しく見てみましょう。

トリガー条件

on:
  pull_request:
    types: [opened, synchronize, labeled, unlabeled]

Pull Request が以下のタイミングで実行されます：

• opened: 新しい Pull Request が作成されたとき
• synchronize: Pull Request にコミットが追加されたとき
• labeled/unlabeled: ラベルが追加・削除されたとき

トリガー設計の考え方

このワークフローでは、あえてトリガーを最小限に抑えてます。

本当はもっと頻繁に実行することもできます：

• schedule で定期実行（1 時間ごととか）
• push イベントで base ブランチへの変更時に全 Pull Request を更新
• workflow_dispatch で手動実行機能

でも、これらを全部有効にすると GitHub Actions の実行時間が月間制限に影響するし、プライベートリポジトリだと課金が発生する可能性があります。なので、GitHub Actions のコストを意識して、必要最小限の自動化にしています。

「完全な自動化」というよりは「手動作業をちょっとでも減らす」感じで、実用性とコストのバランスを取った設計です。

ブランチ更新処理

GitHub の REST API を使って pulls.updateBranch を呼び出し、base ブランチの最新変更を Pull Request のブランチにマージします。

await github.rest.pulls.updateBranch({
  owner,
  repo,
  pull_number: pr.number,
  expected_head_sha: pr.head.sha, // オプティミスティックロック用
});

expected_head_sha を指定することで、更新処理中に他の変更が発生した場合の競合を防いでいます。

エラーハンドリング

コンフリクトが発生した場合は自動更新をスキップし、手動での解決を促すメッセージをログに出力します。

if (error.status === 422 && error.response.data.message.includes("Conflicts")) {
  console.warn(
    `PR #${pr.number} (${pr.head.ref}) has conflicts. Manual intervention needed.`
  );
}

実際に使ってみてどうだったか

この自動化を導入してから、かなり楽になりました：

手動作業が減った
PR作成時やコミット追加時に自動でブランチが更新されるので、Update Branch ボタンを押す頻度がかなり減りました。

Pull Request がいつも最新
常に最新の base ブランチの状態でレビューできるので、古い状態での議論を避けられます。

CI/CD が安定した
最新のコードベースでテストが実行されるので、マージ後の問題を事前に発見しやすくなりました。

新しいメンバーにも優しい
Update Branch ボタンの存在を知らない新しいメンバーでも、自動的にブランチが最新に保たれます。

運用してみて気づいた注意点

ただ、実際に使ってみていくつか気づいた点もあります：

コンフリクトは結局手動で解決
自動更新でコンフリクトが発生した場合は、開発者が手動で解決する必要があります。

マージコミットが増える
base ブランチの更新が多いと、Pull Request に 1 日数回の自動マージコミットが追加されて、実際の開発履歴が見づらくなることがあります。

おわりに

GitHub Actions を使った Pull Request の Update Branch 自動化について紹介しました。

PR作成時やコミット追加時にブランチが自動更新されるようになって、より最新の状態で開発を進められるようになりました。

もしあなたのチームでも「Pull Request の管理がちょっと面倒」とか「Update Branch ボタンって何？」みたいなメンバーがいたら、試してみてください。結構便利ですよ。