masterにpushしないよう注意しましょう

昔はそんなことを気にしていました。今でもそういう現場があるかもしれません。

現在はGitHubのブランチプロテクションという素晴らしいものがあります。使いましょう。無料です。人類の注意力には限りがあるので、仕組みで防ぎましょう。

公式マニュアル

• Defining the mergeability of pull requests - User Documentation

ブランチプロテクションは、リポジトリのAdmin権限を持っているか、OrganizationのOwnerロールであれば、設定できます。ブランチ毎に設定を組み立てます。

設定画面は

リポジトリ -> Settings -> Branches -> Add rule

設定例

例として、gitflowっぽく、

• プルリクは、developから生やして、developにマージする
• developは、masterから生やして、masterにマージする
• hotfixのプルリクは、
  • masterから生やして、masterにマージする
  • developにもマージする

とかそんな運用をしてるイメージで。

develop

• レビュー必須。いつでもapproveしてOK。ただし、approve後に更新されたら、再度approveが必要にする。approve後に、対応漏れが発覚して、追加のcommitした、などの場合を想定してます。
• CIの正常終了が必須
• リポジトリにAdmin権限を持ってるメンバーも例外なく適用

で、画像のようにチェックつけていきます。developブランチへのpushがガードされるのと、developブランチ宛てのプルリクに関して、レビューとかCIとかが必須になります。

master

• レビュー必須。いつでもapproveしてOK。ただし、approve後に更新されたら、再度approveが必要にする。approve後に、対応漏れが発覚して、追加のcommitした、などの場合を想定してます。
• hotfixを想定して、CIの終了は待たずともマージして良いことにする
  • 平時は、プルリクでCI必須にして担保しているから良しとする
  • 緊急時は、レビューで担保する。だって緊急でしょ
• リポジトリにAdmin権限を持ってるメンバーも例外なく適用

masterブランチへのpushがガードされるのと、master宛てのプルリクに関して、設定どおりにガードされます。