GitHub Pull Requestとブランチルールを試す

Git
この記事は約7分で読めます。
記事内に広告が含まれています。

GitHubの基本機能として「Pull Request」があります。

Pull request のドキュメント - GitHub Docs
pull request を使って、プロジェクトへの変更を提案し、自分のプロジェクトに対する変更提案を受け取り、マージの競合などの 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の設定は次のメニューから可能です。

  1. リポジトリ設定(setting)
  2. ブランチ(branches)
  3. ブランチ保護ルール(Branch protection rules)

早速設定します。

リポジトリ設定を表示し、「Branches」メニューから「Add branch protection rule」へ進みます。

2024年後半よりBranches→Branch protection rulesはClassic機能となりました。
→ 現在はRulesetsからNew branch rulesetの設定が標準操作となっています。

※以降の画像は古いときのままです。

ブランチ「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 Request&承認操作

次のユースケースとします。

  1. 変更操作&仮ブランチを作成
  2. 主流←仮ブランチのマージの為に、Pull Requestを発行
  3. Pull Requestで議論
  4. Pull Requestを承認
  5. マージ(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の発行(コメントは適当に)

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年時点)。解決出来ない場合はローカルリポジトリでの対応が必要です。
pull request上でのconflicts解消が出来ない場合。

※バイナリであればgithub.com上で片方選択してマージ解消をしたいものです(いずれアップデートされて出来るようになるのかな)。

まとめ

本記事ではGitHubの基本機能であるPull Requestに関して、必須化とレビュー承認についてご紹介しました。

  • リポジトリ保護ルール(現在はRulesets)からPull Requestのルール設定が出来ます。
  • ルール設定はブランチ毎に出来ます。
  • 適度なルールを設定してコードの品質を保ちましょう。

Pull RequestはGitHubの主機能の1つと認識しています。しっかり使いこなしてGitHubライフを送りましょう。

最後までご覧いただきありがとうございました!

コメント

Top
タイトルとURLをコピーしました