# Managing and standardizing pull requests

Manage and standardize pull requests using templates, code owners, protected branches, rulesets, and automated tools for consistent and secure repository contributions.

If you maintain a repository, you can use GitHub features to make pull requests more consistent and easier to review. Standardization helps contributors know what information to provide, helps reviewers focus on the right changes, and helps protect important branches from accidental or risky merges.

## Using pull request templates

Pull request templates help contributors provide the context your project needs for review. A template can prompt authors to explain the purpose of the change, link related issues, include testing notes, or complete a checklist before requesting review.

Templates are useful when many contributors open pull requests or when your project has review expectations that should be visible every time. See [リポジトリ用のプルリクエストテンプレートの作成](/ja/enterprise-server@3.18/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository), [タスクリストについて](/ja/enterprise-server@3.18/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists), and [プルリクエストを課題にリンクする](/ja/enterprise-server@3.18/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue).

## Defining code owners

Code owners identify the people or teams responsible for specific files or directories. When a pull request changes owned code, GitHub can automatically request a review from the right owners.

Code owners help route reviews to people with the right context. They are especially useful for sensitive areas such as security files, deployment configuration, or shared libraries. See [コードオーナーについて](/ja/enterprise-server@3.18/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

## Using protected branches

Protected branches help keep important branches, such as `main`, stable. They can require conditions such as passing status checks, signed commits, or approving reviews before a pull request can merge.

Use protected branches when a branch represents production code, a release line, or another important source of truth. See [保護されたブランチについて](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).

## Using rulesets

Rulesets let you enforce repository policies across branches and tags. They can require status checks, workflows, pull request reviews, or other conditions before changes are accepted.

Rulesets are useful when you want consistent rules across multiple branches or when you want to combine review requirements with automated security checks, such as dependency review or code scanning merge protection. See [ルールセットについて](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), [organization 全体で依存関係レビューを実施する](/ja/enterprise-server@3.18/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review), and [コード スキャンのマージ保護を設定します](/ja/enterprise-server@3.18/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/set-merge-protection).

## Using push rulesets

プッシュ ルールセットを使用すると、ファイル拡張子、ファイル パスの長さ、ファイルとフォルダーのパス、ファイル サイズに基づいて、プライベート リポジトリまたは内部リポジトリとそのリポジトリのフォーク ネットワーク全体へのプッシュをブロックできます。

プッシュルールはリポジトリへのすべてのプッシュに適用されるため、ブランチのターゲット設定は必要ありません。

プッシュ ルールセットを使用すると、次のことができるようになります。

* **ファイル パスを制限する**: 指定したファイル パスに変更を含むコミットがプッシュされないようにします。

  これには `fnmatch` の構文を使用できます。 たとえば、`test/demo/**/*` を対象とする制限により、`test/demo/` ディレクトリ内のファイルまたはフォルダーへのプッシュが禁止されます。 `test/docs/pushrules.md` を対象とした制限により、`test/docs/` ディレクトリ内の `pushrules.md` ファイルへのプッシュが禁止されます。 詳しくは、「[リポジトリのルールセットの作成](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax)」をご覧ください。
* **ファイル パスの長さを制限する**: 指定した文字制限を超えるファイル パスを含むコミットがプッシュされないようにします。
* **ファイル拡張子を制限する**: 指定したファイル拡張子を持つファイルを含むコミットがプッシュされないようにします。
* **ファイル サイズを制限する**: 指定したファイル サイズの制限を超えるコミットがプッシュされないようにします。

### フォークされたリポジトリのプッシュ ルールセットについて

プッシュ ルールは、リポジトリのフォーク ネットワーク全体に適用され、リポジトリへのすべてのエントリ ポイントが確実に保護されます。 たとえば、プッシュルールセットが有効になっているリポジトリをフォークした場合、フォークされたリポジトリにも同じプッシュルールセットが適用されます。

フォークされたリポジトリの場合、プッシュ ルールのバイパス アクセス許可を持つユーザーは、ルート リポジトリのバイパス アクセス許可を持つユーザーだけです。

Push rulesets help block risky content before it enters the repository. See [ルールセットについて](/ja/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).

## Using automated tools to review code styling

Automated tools, such as linters and formatters, help keep code style consistent across pull requests. They can catch small issues automatically so reviewers can focus on design, correctness, and maintainability.

You can run these tools as part of a continuous integration workflow with GitHub Actions. See [継続的インテグレーション](/ja/enterprise-server@3.18/actions/get-started/continuous-integration).