If you are a repository maintainer, there are several ways that you can manage and standardize the pull requests that contributors create in your repository. These steps can help you ensure that pull requests are reviewed by the right people, and that they meet your repository's standards.
Using pull request templates
Pull request templates let you customize and standardize the information you'd like to be included when someone creates a pull request in your repository. When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body. For more information, see "リポジトリ用のプルリクエストテンプレートの作成."
You can use pull request templates to standardize the review process for your repository. For example, you can include a list of tasks that you would like authors to complete before merging their pull requests, by adding a task list to the template. For more information, see "タスクリストについて."
You can request that contributors include an issue reference in their pull request body, so that merging the pull request will automatically close the issue. For more information, see "Pull RequestをIssueにリンクする."
Defining code owners
You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want a technical writer on your team to always review changes in the docs directory.
You can define individuals or teams that you consider responsible for code or files in a repository to be code owners. Code owners will automatically be requested for review when someone opens a pull request that modifies the files that they own. You can define code owners for specific types of files or directories, as well as for different branches in a repository. For more information, see "コードオーナーについて."
Using protected branches
You can use protected branches to prevent pull requests from being merged into important branches, such as main, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see "保護されたブランチについて."
Using push rulesets
プッシュ ルールセットを使用すると、ファイル拡張子、ファイル パスの長さ、ファイルとフォルダーのパス、ファイル サイズに基づいて、プライベート リポジトリまたは内部リポジトリとそのリポジトリのフォーク ネットワーク全体へのプッシュをブロックできます。
プッシュルールはリポジトリへのすべてのプッシュに適用されるため、ブランチのターゲット設定は必要ありません。
プッシュ ルールセットを使用すると、次のことができるようになります。
-
ファイル パスを制限する: 指定したファイル パスに変更を含むコミットがプッシュされないようにします。
これには
fnmatchの構文を使用できます。 たとえば、test/demo/**/*を対象とする制限により、test/demo/ディレクトリ内のファイルまたはフォルダーへのプッシュが禁止されます。test/docs/pushrules.mdを対象とした制限により、test/docs/ディレクトリ内のpushrules.mdファイルへのプッシュが禁止されます。 詳しくは、「リポジトリのルールセットの作成」を参照してください。 -
ファイル パスの長さを制限する: 指定した文字制限を超えるファイル パスを含むコミットがプッシュされないようにします。
-
ファイル拡張子を制限する: 指定したファイル拡張子を持つファイルを含むコミットがプッシュされないようにします。
-
ファイル サイズを制限する: 指定したファイル サイズの制限を超えるコミットがプッシュされないようにします。
フォークされたリポジトリのプッシュ ルールセットについて
プッシュ ルールは、リポジトリのフォーク ネットワーク全体に適用され、リポジトリへのすべてのエントリ ポイントが確実に保護されます。 たとえば、プッシュルールセットが有効になっているリポジトリをフォークした場合、フォークされたリポジトリにも同じプッシュルールセットが適用されます。
フォークされたリポジトリの場合、プッシュ ルールのバイパス アクセス許可を持つユーザーは、ルート リポジトリのバイパス アクセス許可を持つユーザーだけです。
For more information, see "ルールセットについて."
Using automated tools to review code styling
Use automated tools, such as linters, in your repository's pull requests to maintain consistent styling and make code more understandable. Using automated tools to catch smaller problems like typos or styling leaves more time for reviewers to focus on the substance of a pull request.
For example, you can use GitHub Actions to set up code linters that can run on pull requests as part of your continuous integration (CI) workflow. For more information, see "GitHub Actions による継続的インテグレーションについて."