{"meta":{"title":"Managing and standardizing pull requests","intro":"Manage and standardize pull requests using templates, code owners, protected branches, rulesets, and automated tools for consistent and secure repository contributions.","product":"Pull requests","breadcrumbs":[{"href":"/en/pull-requests","title":"Pull requests"},{"href":"/en/pull-requests/reference","title":"Reference"},{"href":"/en/pull-requests/reference/managing-and-standardizing-pull-requests","title":"Manage and standardize pull requests"}],"documentType":"article"},"body":"# Managing and standardizing pull requests\n\nManage and standardize pull requests using templates, code owners, protected branches, rulesets, and automated tools for consistent and secure repository contributions.\n\nIf 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.\n\n## Using pull request templates\n\nPull 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.\n\nTemplates are useful when many contributors open pull requests or when your project has review expectations that should be visible every time. See [Creating a pull request template for your repository](/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository), [About tasklists](/en/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists), and [Linking a pull request to an issue](/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue).\n\n## Defining code owners\n\nCode 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.\n\nCode 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 [About code owners](/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Using protected branches\n\nProtected 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.\n\nUse protected branches when a branch represents production code, a release line, or another important source of truth. See [About protected branches](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).\n\n## Using rulesets\n\nRulesets 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.\n\nRulesets 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 [About rulesets](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), [Enforcing dependency review across an organization](/en/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review), and [Set code scanning merge protection](/en/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/set-merge-protection).\n\n## Using push rulesets\n\nWith push rulesets, you can block pushes to a private or internal repository and that repository's entire fork network based on file extensions, file path lengths, file and folder paths, and file sizes.\n\nPush rules do not require any branch targeting because they apply to every push to the repository.\n\nPush rulesets allow you to:\n\n* **Restrict file paths:** Prevent commits that include changes in specified file paths from being pushed.\n\n  You can use `fnmatch` syntax for this. For example, a restriction targeting `test/demo/**/*` prevents any pushes to files or folders in the `test/demo/` directory. A restriction targeting `test/docs/pushrules.md` prevents pushes specifically to the `pushrules.md` file in the `test/docs/` directory. For more information, see [Creating rulesets for a repository](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax).\n\n  You can add allowed exceptions for paths that should remain pushable.\n* **Restrict file path length:** Prevent commits that include file paths that exceed a specified character limit from being pushed.\n* **Restrict file extensions:** Prevent commits that include files with specified file extensions from being pushed.\n* **Restrict file size:** Prevent commits that exceed a specified file size limit from being pushed. You can add allowed exceptions for files that may exceed the limit.\n\n### About push rulesets for forked repositories\n\nPush rules apply to the entire fork network for a repository, ensuring every entry point to the repository is protected. For example, if you fork a repository that has push rulesets enabled, the same push rulesets will also apply to your forked repository.\n\nFor a forked repository, the only people who have bypass permissions for a push rule are the people who have bypass permissions in the root repository.\n\nPush rulesets help block risky content before it enters the repository. See [About rulesets](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).\n\n## Using automated tools to review code styling\n\nAutomated 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.\n\nYou can run these tools as part of a continuous integration workflow with GitHub Actions. See [Continuous integration](/en/actions/get-started/continuous-integration)."}