BEACHSIDE BLOG

Azure と GitHub と C# が好きなエンジニアの個人メモ ( ・ㅂ・)و ̑̑

GitHub Enterprise でブランチに push や merge できるユーザーを制限したい

GitHub で特定のブランチに push / merge できるユーザーを制限したいってことはあるでしょうか。そんな設定の話です。


今回取り扱うのは Branch protection rule の「Restrict who can push to matching branches」という設定です。


意訳すると「対象のブランチへ push できるユーザーを制限する」って感じです。

注意として最初に書いておくと、この設定は GitHub Team と GitHub Enterprise Cloud のみで可能な設定です (と、現時点のドキュメントに書いてます)。

このブログを書いた2022年3月時点で私が実際に確認したのは以下です。
GitHub Enterprise Cloud で設定可能、Team プランは未確認 (興味がない)
・Pro プラン、GitHub Enterprise Server (v3.3.4) 、GitHub Enterprise Managed User では設定がない

本題に入る前に一般的によくしてそうなブランチの保護の話をすると、Branch protection rule で以下2つを設定してることが多い気がします 。

  • merge するには Pull request 必須 ("Require a pull request before merging")
  • レビューアーによる承認の必須 ("Require approvals")

これに加え Code Owners のレビューを必須にする設定 ("Require review from Code Owners") もあります。基本的にはこれらの設定がおすすめになります。ちなみに Code Owners の詳細は以前にブログを書きました♪

GitHub の コードオーナー (CODE OWNERS) 機能 マニアックス - BEACHSIDE BLOG

今回は上記の設定ではユースケースに合わない場合のさらなる手段として、「Restrict who can push to matching branches」による 特定のユーザーしか「push できない」(「merge できない」)という設定はどうよって話です。

GitHub Enterprise 設定マニアックスの一員 (謎) である私は設定があること自体は知ってましたが、細かい動作を試したことが無かったので試してみたメモです。

Branch protection rule による設定

冒頭でも書きましたが大事な点なのでもう一度書いておくと、ブログを書いた時点では GitHub Team や GitHub Enterprise Cloud のみで存在する設定です。

Branch protection rule を開く

今回は GitHub Enterprise Cloud で設定を Branch protection の設定を見ていきます。Repository の nav bar にある Settings (①) をクリックすると Repository settings のメニューが表示されます。左メニューの Branches (②) をクリックすると protection rule の一覧が表示されます。設定項目を確認するのに Add ボタン (③) をクリックしてみます。

f:id:beachside:20220302174917p:plain

余談ですが、nav bar で Settings のメニューが存在しない場合、そのユーザーに権限が足りてません。その repository の "Admin" の role である必要があります。細かいことをいうと "Maintain" の role でも Settings** は表示されますが Branches の設定は見れないです。

余談が続きますが、branch protection rule を作成してデフォルトのまま何も設定せずに保存だけすると、そのブランチは削除できなくなるという保護だけがつきます。

Branch protection rule を設定する

branch protection rule を開くと「Restrict who can push to matching branches」があります。ここでユーザーやグループを指定することで、指定した対象のユーザー以外は push できなくなります。

ただし、説明に書いてある通り以下のロールのメンバーはデフォルトで push できるメンバーに含まれているので注意が必要です。

  • Organization の Owner
  • Repository の Admin role
  • Repository の Maintain role

f:id:beachside:20220302181217p:plain

もし設定をした際は、下部にある Save changes ボタンを忘れずに押しましょう。

動作確認

この設定をすると実際どんな動きをするのか見てみましょう。「Restrict who can push to matching branches」に含まれていないユーザーが GitHub 上でファイルを編集して push 仕様とすると、こんな感じで push できんと表示されます。(私が確認したかった唯一の点は、ここの UI がどうなるかでしたw)

f:id:beachside:20220302170030p:plain

じゃーどうすればよいかというと、別ブランチで作業して Pull Request すればよいだけです。普通ですね。

もちろん Pull Request を作成しても、「Restrict who can push to matching branches」に含まれていないユーザーは Merge することができません。

f:id:beachside:20220302170351p:plain

branch protection rule の「Restrict who can push to matching branches」で対象のユーザーのみが merge できます。

f:id:beachside:20220302170439p:plain

まとめ

この設定は柔軟性を感じないので、率先して設定することではないなと感じてます。

ユースケース次第にはなりますが、特定のブランチ (多くの場合 main だと思いますが) で merge を制限したいときの個人的におすすめな設定のこんな感じです。

  • Branch protection rule で Pull request の必須 ("Require a pull request before merging") と、レビューアーによる承認の必須 ("Require approvals") の設定をする。
  • これで事足りなければ Code Owners のレビューを必須 ("Require review from Code Owners") を設定する。
  • "Restrict who can push to matching branches" しかユースケースに合わないときは、設定をする。

です。

もちろん今回の設定はシンプルに設定できるって意味で便利ではありますのでユースケース次第ですがね。

Code Owners は、例えば monorepo でフロントエンドとバックエンドのコードが混在していた場合でも、変更されたフォルダに合わせて必須の承認者を自動で強制的にレビューアーとして追加できるので ("Require review from Code Owners") 、それが最も柔軟で実用的な制約と思います。

さらに、Staging 環境や QA 環境で品質チェックをして承認をしたいなら、GitHub Actions + Environment の設定でデプロイ時に承認者を設定するのがベターなので、ブログを書いておいてなんですが今回の設定はさほど出番がないと感じてます。

参考

docs.github.com