git push事故を、気合ではなく、GitHub Branch Protectionで防ぐ
masterにpushしないよう注意しましょう
昔はそんなことを気にしていました。今でもそういう現場があるかもしれません。
現在はGitHubのブランチプロテクションという素晴らしいものがあります。使いましょう。無料です。人類の注意力には限りがあるので、仕組みで防ぎましょう。
公式マニュアル
ブランチプロテクションは、リポジトリの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宛てのプルリクに関して、設定どおりにガードされます。
Author And Source
この問題について(git push事故を、気合ではなく、GitHub Branch Protectionで防ぐ), 我々は、より多くの情報をここで見つけました https://qiita.com/sasasin/items/eb4ca7ab2cc5f0bd9d29著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .