# 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 [리포지토리에 대한 끌어오기 요청 템플릿 만들기](/ko/enterprise-server@3.20/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository), [작업 목록 정보](/ko/enterprise-server@3.20/get-started/writing-on-github/working-with-advanced-formatting/about-tasklists), and [끌어오기 요청을 이슈에 연결](/ko/enterprise-server@3.20/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 [코드 소유자 정보](/ko/enterprise-server@3.20/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 [보호된 분기 정보](/ko/enterprise-server@3.20/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 [규칙 세트에 대한 정보](/ko/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), [조직 전반에서 종속성 검토를 강제하기](/ko/enterprise-server@3.20/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review), and [코드 검사 병합 보호 설정](/ko/enterprise-server@3.20/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` 파일에 대한 푸시를 방지합니다. 자세한 내용은 [리포지토리에 대한 규칙 세트 만들기](/ko/enterprise-server@3.20/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 [규칙 세트에 대한 정보](/ko/enterprise-server@3.20/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 [연속 통합](/ko/enterprise-server@3.20/actions/get-started/continuous-integration).