【github】mainブランチに対して直接pushを禁止する保護ルールを設定をする
TL;DR
GitHubの保護ブランチ機能は、重要なブランチの安全性と整合性を確保するための強力なツールです。ブランチ保護ルールを設定することで、誤ったプッシュや削除、強制プッシュを防止し、プルリクエストのレビュー、ステータスチェックのパス、コミット履歴の線形性など、一定の要件を満たすまでブランチへの変更を制限することができます。これにより、コードベースの安定性を保ちながら、チームの効率的なコラボレーションを支援します。これらの設定に関して自分が設定することで推奨すべき内容をピックアップして紹介できればと思います。
ブランチ保護ルールの基本
GitHubのブランチ保護ルールは、リポジトリ内の重要なブランチを保全し、安全に管理するための強力なメカニズムです。これらのルールを設定することで、コラボレータがブランチに変更を加える前に、一定の条件やプロセスを満たす必要があります。これには、プルリクエストを通じたマージも含まれます。ただし、バイパスリストへのアクターの追加は組織に属するリポジトリでのみ可能です。
デフォルト設定とカスタマイズ
デフォルトでは、ブランチ保護ルールはフォースプッシュを防ぎ、ブランチの削除を禁止します。しかし、これらの設定は必要に応じて変更することができます。また、追加の保護機能を有効にすることも可能です。
管理者への適用
通常、ブランチ保護ルールはリポジトリの管理者や特別な権限を持つカスタムロールには適用されません。しかし、必要に応じてこれらのアカウントに対してもルールを強制することが可能です。
ブランチの対象範囲
ブランチ保護ルールは、特定のブランチ、すべてのブランチ、または特定のパターンにマッチするブランチに対して設定できます。例えば、「release」という言葉を含むブランチを保護する場合は、「release」というパターンを使ってルールを作成します。
自動マージのオプション
マージの要件がすべて満たされた場合に、プルリクエストを自動的にマージするよう設定することもできます。これにより、効率的なワークフローを実現できます。
1つのルール制限
重要な点として、一度に1つのブランチ保護ルールのみが適用されることを覚えておいてください。これは、複数のルールが同一のブランチに適用されると混乱を招く可能性があるためです。
設定方法について
それでは設定方法について見ていきましょう。
まず、任意のリポジトリの Settings > Branchesを選択してください。
そうすると Branch protection rule の画面になりますのでここで Add branch protection ruleを押下して、ルール設定に進みます。
次に、Branch protection ruleについてこのフローで選択することができます。
ここで複数のルールが設定できます。設定可能なルールについて見ていきましょう。
| Item | Sub Item | 説明 | 個人 | Organization |
|---|---|---|---|---|
| Require a pull request before merging | マージする前に、プルリクエストを要求する。有効にすると、すべてのコミットは、このルールに一致するブランチにマージされる前に、保護されていないブランチに作成され、プル リクエスト経由で送信される必要があります。 | ○ | ○ | |
| Require approvals | プルリクエストにおいて、承認 (approval) を要求する | ○ | ○ | |
| Dismiss stale pull request approvals when new commits are pushed | 新しいコミットがプッシュされたときに古い承認を取り消す、一致するブランチにプッシュされた新しいレビュー可能なcommitは、Pull Requestのレビュー承認を却下します。 | ○ | ○ | |
| Require review from Code Owners | Code Ownersによるレビューを要求する | ○ | ○ | |
| Restrict who can dismiss pull request reviews | プルリクエストのレビュー (変更を要求するレビュアによる承認を必要とする承認) を却下できる人を制限する | × | ○ | |
| Allow specified actors to bypass required pull requests | 指定したユーザーに対し、プルリクエストの要求を免除さない | × | ○ | |
| Require approval of the most recent reviewable push | 直近のレビュー可能なプッシュを、プッシュした本人以外の誰かが承認しなければならないかどうか。 | ○ | ○ | |
| Require status checks to pass before merging | マージする前に、status checkをクリアしていることを要求する | ○ | ○ | |
| Require branches to be up to date before merging | マージする前に、作業ブランチが最新 (マージ先のブランチの変更が取り込まれている) であることを要求する | ○ | ○ | |
| Require conversation resolution before merging | マージする前に、プルリクエストのconversation (コメント) が解決されていることを要求する | ○ | ○ | |
| Require signed commits | 署名付きのコミットを要求する | ○ | ○ | |
| Require linear history | 履歴の分岐を許さない | ○ | ○ | |
| Require merge queue | マージキューを要求する | × | ○ | |
| Require deployments to succeed before merging | マージする前に、deploymentsが成功することを要求する | ○ | ○ | |
| Lock branch | ブランチをロックする (ブランチを変更する) | ○ | ○ | |
| Do not allow bypassing the above settings | (管理者とカスタムロールで"bypass branch protections"の権限を持つユーザーに対し) 上記の設定のbypassを許さない | ○ | ○ | |
| Restrict who can push to matching branches | 対象のブランチに対し、pushできる人を制限する | × | ○ | |
| Restrict pushes that create matching branches | 命名規則が合致するブランチの作成ができる人を制限する | × | ○ |
「Save changes」を押下すれば設定は完了です。お疲れ様でした！ これで保護ルールの設定は以上です。
最後に
githubの保護ルールについてでした。開発の上で何かの役に立てば幸いです。それでは。
no plan株式会社について
- no plan株式会社は 「テクノロジーの力でZEROから未来を創造する、精鋭クリエイター集団」 です。
- ブロックチェーン/AI技術をはじめとした、Webサイト開発、ネイティブアプリ開発、チーム育成、などWebサービス全般の開発から運用や教育、支援なども行っています。よくわからない、ふわふわしたノープラン状態でも大丈夫！ご一緒にプランを立てていきましょう！
- no plan株式会社について
- no plan株式会社 | web3実績
-
no plan株式会社 | ブログ一覧
エンジニアの採用も積極的に行なっていますので、興味がある方は是非ご連絡ください！ - CTOのDMはこちら
Reference
Discussion