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 "끌어오기 요청을 이슈에 연결."
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를 사용한 연속 통합 정보."