【GitHub】Branch protection ruleの運用ルールを作った話

この記事はMicroAd (マイクロアド) Advent Calendar 2020 - Qiitaの6日目の記事です。

---

前書き

この記事では、自分の所属しているチームが主に開発しているGitHub¹リポジトリに関してBranch protection ruleの運用ルールを作った話についてまとめます。

背景

弊チームでは元々Branch protection ruleをなんとなくで運用していましたが、rebase等の操作に伴って外したプロテクションの戻し忘れが発生したり、手伝いに入って貰った別チームから「うちは個別のBranch protection ruleで運用したい」といった要望が出たため、正式に運用ルールを整えることにしました。

設定した運用ルール

運用ルールは最終的に以下のような形になりました²。

• よく使う名前のブランチは包括的にプロテクションをかけておく（これらのルールは編集禁止）
  • master
  • release
  • *_feature（個別の案件系ブランチ）
• 特殊な操作・運用が必要な場合、個別のブランチに関するプロテクションを立て、そちらで制約を緩める
• 不要になったプロテクションはなる早で削除する

これらのプロテクションを入れると以下のようになります³。

以下に機能面での解説をします。

正規表現を用いたプロテクション

弊チームでは、個別の案件系ブランチには${案件の識別番号}_featureという名前を付けています。
これらのブランチは並行で複数存在するため、基本的なプロテクションはワイルドカード構文を用いて行うこととしました。

これによって、featureブランチを作る度に一々プロテクションを作る必要が無くなります。

個別のブランチプロテクション

正規表現を用いたプロテクションは、より具体的な名前のプロテクションで上書きすることができます。

例えば、hoge_featureという名前のブランチに対してhoge_featureと*_featureというプロテクションが有った場合は前者が優先的に適用されます。
つまり、*_featureプロテクション内でforce pushが禁止されていても、hoge_feature内でforce pushを許可することで、hoge_featureへのforce pushを可能にするようなこともできます。

これによってチームごとにプロテクションルールを設定したり、個別のブランチに対する操作の間だけ制約を緩めるようなことができます。

今回の運用ルール制定前は全体へのプロテクションを弄って制約を緩めるようなこともしていましたが、戻し忘れた際の影響が大きいということで、必要になった場合だけ個別に立ててすぐ消すという運用に落ち着きました。

おまけ

featureブランチに実際に設定しているBranch protection ruleを載せます。

主に設定していること

• マージ前に1人以上のレビュー必須
• CI（テストとlint）の成功必須
  • このリポジトリには2種類のCIが設定されていて、featureではチェックを付けている片方のみ動かしているため、チェックは動かしている方にだけ付けています
• マージ前のrebase必須
• 管理者にもルールを適用
• push禁止（force pushだけでなくブランチへのpushそのものを禁止）

終わりに

今回はBranch protection ruleの運用ルールを作った話に関してまとめました。
合わせてBranch protection ruleそのものも整備しましたが、色々な事故のリスクが減って良かったです。

明日は@taka_maenishiによる「PySparkでarray<struct>のフィールドを操作する」記事です。

• MicroAd (マイクロアド) Advent Calendar 2020 - Qiita

公式資料

• 保護されたブランチを設定する - GitHub Docs

1. 正確にはGitHub Enterpriseですが、ややこしいのでGitHubと書いています。 ↩

2. hotfix系などは*_featureと同様のプロテクションをかけていますが、記事中では省略します。 ↩

3. 形だけ再現したものなのでCurrently appliesが0になっていたりしますが、実際はここにプロテクションが当たっているブランチの数が出ます。 ↩