리포지토리 유지 관리자인 경우 기여자가 리포지토리에서 만드는 끌어오기 요청을 관리하고 표준화할 수 있는 여러 가지 방법이 있습니다. 이러한 단계는 올바른 사용자가 끌어오기 요청을 검토하고 리포지토리의 표준을 충족하는지 확인하는 데 도움이 될 수 있습니다.
끌어오기 요청 템플릿 사용
끌어오기 요청 템플릿을 사용하면 리포지토리에서 끌어오기 요청을 만들 때 포함할 정보를 사용자 지정하고 표준화할 수 있습니다. 리포지토리에 끌어오기 요청 템플릿을 추가하면 프로젝트 기여자가 끌어오기 요청 본문에서 템플릿의 콘텐츠를 자동으로 볼 수 있습니다. 자세한 내용은 리포지토리에 대한 끌어오기 요청 템플릿 만들기을(를) 참조하세요.
끌어오기 요청 템플릿을 사용하여 리포지토리에 대한 검토 프로세스를 표준화할 수 있습니다. 예를 들어 템플릿에 작업 목록을 추가하여 끌어오기 요청을 병합하기 전에 작성자가 완료할 작업 목록을 포함할 수 있습니다. 자세한 내용은 작업 목록 정보을(를) 참조하세요.
끌어오기 요청을 병합하면 문제가 자동으로 닫히도록 기여자가 끌어오기 요청 본문에 문제 참조를 포함하도록 요청할 수 있습니다. 자세한 내용은 끌어오기 요청을 이슈에 연결을(를) 참조하세요.
코드 소유자 정의
특정 개인이 항상 리포지토리의 특정 코드 또는 파일에 대한 변경 내용을 검토하도록 할 수 있습니다. 예를 들어 팀의 기술 작성자가 docs 디렉터리의 변경 내용을 항상 검토하도록 할 수 있습니다.
리포지토리의 코드 또는 파일을 담당하는 개인 또는 팀을 코드 소유자로 정의할 수 있습니다. 코드 소유자는 자신이 소유한 파일을 수정하는 끌어오기 요청을 다른 사용자가 열 때 자동으로 검토 요청을 받습니다. 리포지토리의 여러 분기뿐만 아니라 특정 형식의 파일 또는 디렉터리에 대한 코드 소유자를 정의할 수 있습니다. 자세한 내용은 코드 소유자 정보을(를) 참조하세요.
보호된 분기 사용
보호된 분기를 사용하여 특정 조건이 충족될 때까지 끌어오기 요청이 중요한 분기(예: main)로 병합되는 것을 방지할 수 있습니다. 예를 들어 CI 테스트 또는 승인 검토를 통과해야 할 수 있습니다. 자세한 내용은 보호된 분기 정보을(를) 참조하세요.
푸시 규칙 집합 사용
푸시 규칙 집합을 사용하면 파일 확장명, 파일 경로 길이, 파일 및 폴더 경로, 파일 크기에 따라 프라이빗 또는 내부 리포지토리와 해당 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단할 수 있습니다.
푸시 규칙은 리포지토리에 대한 모든 푸시에 적용되므로 분기 대상 지정이 필요하지 않습니다.
푸시 규칙 집합을 사용하면 다음을 수행할 수 있습니다.
-
파일 경로 제한: 지정된 파일 경로의 변경 내용이 포함된 커밋이 푸시되지 않도록 합니다.
이 테스트에
fnmatch구문을 사용할 수 있습니다. 예를 들어test/demo/**/*를 대상으로 하는 제한은test/demo/디렉터리의 파일이나 폴더에 대한 푸시를 방지합니다.test/docs/pushrules.md를 대상으로 하는 제한 사항은test/docs/디렉터리의pushrules.md파일에 대한 푸시를 방지합니다. 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기" 항목을 참조하세요. -
파일 경로 길이 제한: 지정된 문자 제한을 초과하는 파일 경로가 포함된 커밋이 푸시되지 않도록 합니다.
-
파일 확장명 제한: 지정된 파일 확장명의 파일이 포함된 커밋이 푸시되지 않도록 합니다.
-
파일 크기 제한: 지정된 파일 크기 제한을 초과하는 커밋이 푸시되지 않도록 합니다.
포크된 리포지토리에 대한 푸시 규칙 집합 정보
푸시 규칙은 리포지토리의 전체 포크 네트워크에 적용되어 리포지토리에 대한 모든 진입점이 보호되도록 합니다. 예를 들어 푸시 규칙 집합을 사용하도록 설정된 리포지토리를 포크하는 경우 포크된 리포지토리에도 동일한 푸시 규칙 집합이 적용됩니다.
포크된 리포지토리의 경우 푸시 규칙에 대한 바이패스 권한이 있는 사람은 루트 리포지토리에서 바이패스 권한이 있는 사용자뿐입니다.
자세한 내용은 규칙 세트 정보을(를) 참조하세요.
자동화된 도구를 사용하여 코드 스타일 검토
리포지토리의 끌어오기 요청에서 linter와 같은 자동화된 도구를 사용하여 일관된 스타일을 유지하고 코드를 더 쉽게 이해할 수 있도록 합니다. 자동화된 도구를 사용하여 오타나 스타일 지정과 같은 작은 문제를 포착하면 검토자가 끌어오기 요청의 내용에 집중할 수 있는 시간이 더 늘어납니다.
예를 들어 GitHub Actions을(를) 사용하여 CI(연속 통합) 워크플로의 일부로 끌어오기 요청에서 실행할 수 있는 코드 linter를 설정할 수 있습니다. 자세한 내용은 GitHub Actions를 사용한 연속 통합 정보을(를) 참조하세요.