GitHubの基本機能として「Pull Request」があります。
本記事ではPull Requestについて以下の点でご紹介します。
- Pull Requestの必須化
- Pull Requestの承認機能
Pull Requestとは・・・？
Pull Requestとはコード変更を提案するための機能で、リポジトリのオーナーやチームメンバーに変更内容をレビューしてもらうことができます。Pull Requestを作成することで、コード変更に対するフィードバックを受け取り、問題を修正してからコードをマージすることができます。
→ Pull Requestは、ブランチからブランチのマージが前提です。言い換えれば、開発ブランチを主流ブランチにマージする際の「確認作業」がPull Requestとも呼べます。
※Pull Requestの必須化や承認機能（総じて”ブランチ保護ルール”）をPrivateリポジトリで使うためにはTeam以上のプランが必要です（Free版はPublicリポジトリで利用可）。
以下、目次です！
試しながらご紹介
前提条件
- ブランチ「main」に対する変更はPull Requestを必須化します。
→ mainに対する直接コミットは禁止ということ。 - Pull Requestにはレビューア1人以上の承認が必要とします。
設定操作
リポジトリ設定はリポジトリ権限が「Admin」である必要があります。
Pull Requestの設定は次のメニューから可能です。
- リポジトリ設定（setting）
- ブランチ（branches）
- ブランチ保護ルール（Branch protection rules）
早速設定します。
リポジトリ設定を表示し、「Branches」メニューから「Add branch protection rule」へ進みます。
ブランチ「Branch protection rule」（ブランチ保護ルール）画面が表示されました。
ブランチ保護ルールは「Pull Request」以外にも色々な設定が可能です。例えば、
- 線形履歴の要求
→ Squash and merge, Rebase and mergeだけとなる。 - ブランチロック（変更保護）
- ルールは管理者にも適用する（バイパスさせない）
- 強制Pushを許可
などです。
今回は「main」ブランチに対して「Pull Request」に関する設定を行いたいので、Branch name petternにmainと入力して、Require approvalsにチェックを入れます。
必要な承認数は1～6を選択可能ですが、今回は1とします。
また、今回はリポジトリAdminにもこのルールを適用するため、下の方にある「Do not allow bypassing the adove settings」にチェックを入れておきます。
最後に画面下部の「Create」を押下して設定完成です。
このようにブランチ毎にルール設定が可能です。
Pull Req＆承認操作
次のユースケースとします。
- 変更操作＆仮ブランチを作成
- 主流←仮ブランチのマージの為に、Pull Requestを発行
- Pull Requestで議論
- Pull Requestを承認
- マージ（Pull Request終了）
今回はGitHub.com上（ブラウザ上）で全ての操作を行っていきます。
まずはmainブランチ上の適当なファイルを変更して、コミットしようとすると、直接のコミットは出来ません。「Crate a new branch for this commit and start a pull request.」しか選択できないため、一時的なブランチに対してのコミットとなります。
続いて、pull requestの発行画面に自動的に遷移します（後から手動でも発行可）。
「main」ブランチに対して「main-patch-1」をマージしたいという、pull requestを発行します。
pull requestが発行されました。
「Review required」とあります。
→ レビュー承認が無いとマージがブロックされている、ということです。
※All checks haves passedというのがありますが、これはpull request発行契機のActionsが動作した場合に表示されます。Actions（例えばコードチェックやビルド）をpull requestの条件に追加することも可能です（今回は詳細は割愛。将来的にActionsの記事を書く予定。）
本人は承認カウントに含まれないため、他の担当者に依頼して、レビューを承認してもらいます。なお、pull requestの画面からレビューアを割り当てると、該当者にはメール通知が行われます。
私がレビューアか。
レビューアは「Add your review」をクリックし、内容を確認します。問題がなければ「Review changes」をクリックしてコメント入力しつつ「Approve」を選択して「Submit review」をクリックします。
今回の承認数は「1」としているため、pull requestの条件は次のように達成します。
「Merge pull request」をクリックすると、マージが実行されます。元々のブランチが不要であれば、この画面から削除（Delete branch）することも可能です。
※今回は詳しく触れませんが、Pull Request発行時にActionsを利用したコードチェックを行って、エラーが無いことをPull Requestの条件にすることも可能です。またどこかで紹介できればと思います。
ところで、Pull Requestのマージ方法には3種類あり、別記事で違いを紹介しています。
(その他) 承認拒否やPullReq拒否は？
次のパターンが考えられるます。
- 承認拒否
→ 承認拒否の理由に合わせて、マージ元ブランチの内容を変更して再承認依頼でしょうか。（マージ元のブランチを更新すれば、元々のPull Requestにも変更内容が反映される） - PullRequest拒否
→ 全否定の場合は、そのままPull RequestをCloseになります。何もマージされません。
(その他) Conflict時のマージ
Pull RequestでConflict発生時の対応は次の通りです。
- 自動マージ可能
→ pull request上で自動マージとなります。 - 自動マージ不可能
→ テキストファイルで単純な変更であればGitHub上で選択可能です。複雑であったり、バイナリファイルが含まれる場合はGitHub上での解決は現状出来ません（2024年時点）。解決出来ない場合はローカルリポジトリでの対応が必要です。
※バイナリであればgithub.com上で片方選択してマージ解消をしたいものです（いずれアップデートされて出来るようになるのかな）。
まとめ
本記事ではGitHubの基本機能であるPull Requestに関して、必須化とレビュー承認についてご紹介しました。
- リポジトリ保護ルールからPull Requestのルール設定が出来ます。
- ルール設定はブランチ毎に出来ます。
- 適度なルールを設定してコードの品質を保ちましょう。
Pull RequestはGitHubの主機能の1つと認識しています。しっかり使いこなしてGitHubライフを送りましょう。
最後までご覧いただきありがとうございました！
コメント