非レビューコードと力コードレビュー文化からGithubプロジェクトを保護する方法

このブログ記事では、私たちはあなたに、非査読されたコードのランダムなプッシュからgithubリポジトリを保護する方法を示します、あるいは、master/mainブランチにプッシュします.私はコードレビューでプル要求を介して機能を展開する強い信者です.私は、ブランチとプルのリクエストのワークフローが良いか悪いかどうかは質問にはならない、私はそれがプル要求とコードのレビューは、学習したいチームのために必要であるという私の意見を持っていないので、あなたが同意しない場合は、この記事はあなたのためではないので、それはすべてのチームメンバーがそれを使用するように強制されます.
コードレビューは、文化に依存する実践です.継続的な学習、共有、チームワークのための大きな願いを持つ自我のない文化.コードを学習する以外に、コードのレビューは、あなたが良い指導者かどうかを表示されます過酷なことなく、明確かつプロフェッショナルである必要があるようにあなたのコミュニケーションソフトスキルを向上させます.
この記事は、コードレビューの練習でプル要求を達成するために3ステップに焦点を当てます.
理論の

ワークフロー

プロジェクトを設定する
プルリクエストテンプレートを作成

ワークフロー
Githubではmasterから新しいブランチを作成し、分岐の標準命名規則を使用します.

feature/name-of-the-feature

fix/name-of-the-fix

レビュアーのために非常に時間がかかる非常に大きなプル要求を作成するのを避けるために、すべて242479142/featureのためにこれをしてみてください.
2 .作業終了後、あなたのコードをfix/featureブランチにプッシュして、この分岐をfixブランチに結合するようにプル要求を作成します.
コードレビューのために誰かを割り当てる.ここでの目標は、お互いから学び、すべての標準が満たされ、コードのスタイルが尊重されることを確認することであり、もちろん、コードにはバグがないことを確認することです.
4 .コードレビューを行っている人から要求された質問/提案/修正/変更があれば、その人は明確なコメントでgithubの変更を要求します、そして、プロセスは再び始まります.すべてのコメントは、レビュアーがプルリクエストを受け入れる前に解決する必要があります.
成功したコードレビューの後、ブランチはmasterブランチにマージされ、master/featureブランチが自動的に削除されます.

プロジェクトの設定

ファイルを作成する
コード所有者ファイルは、リポジトリ内のコードに責任がある個人やチームを定義します.コード所有者は自動的に誰かが自分のコードを変更するプル要求を開いたときに確認要求されます.fixファイルを使用するには、コードの所有者を追加したい枝のCODEOWNERS、CODEOWNERS、またはCODEOWNERSディレクトリ内のrootという新しいファイルを作成します.私は単純な男であるので、私は常にdocs/にすべてを置きました.別の支店の異なるコードの所有者を割り当てることができます.実際には、誰もコードの所有者の承認なしにプル要求を承認することができます.これは開発者が誰も承認しないプル要求をマージしようとしてから保護します.
例.github/ファイル

* @marioloncarek

2 .ユーザロールの管理
GitHubリポジトリではrootタブに進み、左メニューからCODEOWNERSを選択します.ここでは、どのユーザーがレポジトリにアクセスできるかを定義できます.常に少なくとも1つの管理者を持ち、他のすべての開発者は書き込み権限を持つことができます.実際には、管理者はこの記事からすべてをオーバーライドし、マスターブランチまたはフォースの変更を確認せずに権限を使用できます.これは、ホットフィックスに役立つ可能性があります.


ブランチ保護設定の設定
GitHubリポジトリではSettingsタブに進み、左メニューからManage accessを選択します.Settingsの下でBranchesをクリックします.

これはブランチ保護構成を開きます.Branch protection rulesの下で、あなたの主な支店名(おそらくAdd rule)またはあなたが保護したい他のどの枝も書きます.このイメージに従ってすべてのオプションを設定します

この設定は次のようになります.

を合併する前に、プル要求レビューを必要とします

はコード所有者

から批評を必要とします

は、誰がプル・リクエストレビューを終えることができるかについて制限します

は、

を合併する前にステータスチェックを通過するのを必要とします

は、

を合併する前に、分岐を最新にするのを必要とします

を合併する前に会話解決を必要とする

は誰が一致する枝

にプッシュすることができます制限します

強制的にプッシュアクセス

ですべてのユーザーのプッシュプッシュ

は、一致するブランチ

を削除するためにプッシュ・アクセスでユーザーを不許可にします

ファイルを作成する
あなたのリポジトリにプル要求テンプレートを追加すると、プロジェクトの貢献者は、プル要求本文でテンプレートの内容を自動的に表示します.
あなたのプルリクエストテンプレートをリポジトリのルートディレクトリに表示するには、プルリクエストテンプレートBranch name patternに名前を付け、リポジトリのmasterに置きます.
今、貢献者が新しいプル要求を作成するとき、彼らはプル要求をより標準化し、貢献者がチェックリストを使用してプロジェクト(標準、コードスタイル、ビルドフローなどのような)に重要なものについて思い出させることができるテンプレートを見るでしょう.
例pull_request_template.mdファイル

## Description

Please include a summary of the change or which issue is fixed.

## Type of change

- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

## Area of change

- [ ] Frontend
- [ ] Backend

## General checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I ran `npm run format`/`yarn format` before commit
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation where needed
- [ ] My changes generate no new warnings
- [ ] I have checked my code and corrected any misspellings
- [ ] I have updated `master` and merged to my branch before submitting pull request
- [ ] My pull request generate no conflicts with `master` branch
- [ ] I requested code review from other team members

## Frontend checklist:

- [ ] I followed guidelines for `HTML`/`LIQUID`, `SCSS`, `JAVASCRIPT` from readme
- [ ] My `Javascript` generate no new console errors  
- [ ] I tested my code cross browsers
- [ ] My slice is pixel perfect for both desktop and mobile according to design
- [ ] I conducted basic QA to assure all features are working
- [ ] I tested responsive for mobile and tablet resolutions

## Backend checklist:

- [ ] I tested admin by manually adding content from zero
- [ ] I followed guidelines for naming admin fields
- [ ] I created easy to use admin experience which is self-explanatory
- [ ] I added description to admin fields in hard-to-understand areas
- [ ] I followed guidelines for naming `php`/`liquid` variables
- [ ] I conducted basic QA to assure all features are working

結論
これらの3つのセットアップステップは、非審査されたコードのプッシュに対するリポジトリの強力な保護を作成するか、直接マスター/メインブランチにプッシュします.それは、チームに規則を適用して、コードレビュー文化を維持させます.
それは人々がルールに従うことを強制することは必ずしも簡単ではないが、提案を投稿全体で与えられた、あなたはすぐに、誰もがそれを次のように確認するために自動化することができます.
上記の規則についてどう思いますか.あなたのチームのワークフローを改善するために他のアドバイスがありますか?