一人で開発している時に、自分で立てたPull Requestが「Review required」と出るせいでmergeできない問題を解決する方法

対象読者

GitHubを使い、Pull Requestを駆使して一人で開発している初心者。
または、この問題に遭遇し解決できないでいる全ての人々。

前提条件

• GitHubを使っている
• そのリポジトリの所有者（管理者）は自分

導入。あるいはポエム

趣味でOSSを開発している場合、たいていの場合はたった独りで開発することになるでしょう。GitHubのリポジトリを作ったら、そこにcommitするのは自分だけ。そんな開発は、決して珍しくはないはずです。

さて、GitHub Flowで開発を行う場合、mainブランチ（人によってはmasterブランチかもしれません）に直接commitしません。代わりに、ブランチを切ってcommitし、そのブランチをgit pushしてから、GitHub上でプルリクエストを作成し、それをマージする運用になります。

自分で立てたPull Requestに、自分でコメントしたり、誰も見てないのに凝ったPull Requestの概要を書いてみたり、独りにも関わらずcommit messageの一人称で"we"を使ってみたり。さあ、作業は終わりだ！いよいよマージするぞ！！

そう思うあなたの眼前に、次のメッセージが表示されます。

「Review required」と「Merging is blocked」の文字。これのせいでmergeできません。プルリクをマージするためには、まずレビューしてもらい、Approve（承認）をもらう必要があるのです。でも、そんな人はいません。なぜなら、これはあなた一人だけのプロジェクトだから！

レビューが必要とのことなので、自分でレビューをしましょう。「Files changed」タブを開き、「Review changes」ボタンを押します。開いた画面の中にある「Approve」を選択し、「Submit review」を押すだけです。commentは書かなくても大丈夫です。

「Approve」を選択できません。カーソルを重ねて出るのは「Pull request authors can’t approve their own pull request」というメッセージ。

そう、GitHubでは、自分で立てたPull RequestをReviewすることはできないのです。それは、たとえあなたがこのリポジトリの所有者であり、唯一のContributorであっても変わりません。

解決策その1 - 管理者権限を使う

※このやり方はオススメしません。

自分で自分のPull Requestにレビューを送ることはできません。しかし、あなたは所有者です。よって設定を変え、強引にマージすることはできます。

「Settings」タブを開き、「Branches」内の「Branch protection rules」を「Edit」しましょう。

設定画面の下の方に「Do not allow bypassing the above settings」という項目があるはずです。

そのチェックを外し、「Save changes」を押します。

これで、プルリクを強引にマージすることができるでしょう

「Merge without waiting for requirements to be met (bypass branch protections)」をチェックし、mergeしてください。

解決策その2 - Botにレビューしてもらう

解決策その1は、全てのcheckを無視できてしまいます。せっかく設定したCIも、Code Climateも、全部無視することが可能です。せっかくBranch protectionを設定したのに、唯一の開発者である自分が回避できてしまっては意味がないでしょう。

え、Branch protectionなんて設定していない？いえ、過去のあなたは設定したはずです。でなければ、そもそも「Review required」なんて表示は出ないですからね。

過去に行った事を覚えていないのが人間というもの。うっかりミスを回避するためにも、「管理者の自分でさえ、全てのcheckが成功しなければマージできない」という安全策は必要です。

では、merge前にレビューが必要になってしまうこの問題をどう解決するか？自分でレビューできないなら、Botにレビューしてもらいましょう！

.github/workflowsディレクトリ¹を作成し、その中に適当な名前のYAMLファイルを置きます。例えば、pr-auto-approve.yamlとか。そして、以下の内容を書きます。

.github/workflows/pr-auto-approve.yaml

name: Auto Approve
on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review
jobs:
  approve:
    if: |
      github.event.pull_request.user.login == github.repository_owner
      && ! github.event.pull_request.draft
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: hmarr/auto-approve-action@v3

そうです。これはGitHub Actionsです。素晴らしいhmarr/auto-approve-actionを使い、自動でレビューしてもらうのです。

書いたYAMLファイルをcommitし、GitHubに送信してPull Requestを作成しましょう。正しく動作していれば、このファイルをcommitしたそのプルリクも自動でレビューされ、以下の表示になるはずです

これをマージすれば、これから作るプルリクエストは自動でレビューされます。

※既に開いているプルリクエストの場合は、各プルリクで「Update branch」ボタンを押して、ブランチをmainブランチと同期したら自動レビューされるようになります。

やや詳細な解説

コメント付きのコードを再掲します。

name: Auto Approve
# このGitHub Actionsを起動するイベントの種類
on:
  # Pull Request関係のイベント
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review # Draft Pull RequestからDraftが外れたら起動
jobs:
  approve:
    # このJobを実行する条件。以下の全てを満たす場合
    # + Pull Requestの作成者が、リポジトリ所有者と等しい
    # + Pull Requestが、Draft Pull Requestではない
    if: |
      github.event.pull_request.user.login == github.repository_owner
      && ! github.event.pull_request.draft
    # このJobを実行する時に使うOS
    # 今回は何でもいいが、GitHub Actionsでは指定が必須
    runs-on: ubuntu-latest
    # 内部で使用されるGitHub APIの権限を上書き
    permissions:
      pull-requests: write
    steps:
      # Pull RequestをApproveする
      - uses: hmarr/auto-approve-action@v3

hmarr/auto-approve-actionは、Pull RequestをApproveします。ただそれだけです。よって、「どのようなPull RequestならApproveするか」は、if条件文で指定しています。

• github.event.pull_request.user.login == github.repository_owner

  Pull Requestの作成者が、リポジトリ所有者と等しい。

• ! github.event.pull_request.draft

  Pull Requestが、Draft Pull Requestではない。

この2つの条件が満たされた場合に、hmarr/auto-approve-actionを実行します。

その他の書き方に関する情報は、公式のドキュメントを参照してください。

GitHub Actionsのドキュメント - GitHub Docs

1. .githubフォルダを作り、その中にさらにworkflowsフォルダを作る、の意味です。 ↩