끌어오기 요청 모범 사례

끌어오기 요청 만들기 모범 사례

끌어오기 요청을 만들 때 더 원활한 검토 프로세스에 대한 몇 가지 모범 사례를 따릅니다. 끌어오기 요청 만들기에 대한 자세한 내용은 "끌어오기 요청 만들기"을(를) 참조하세요.

작은 PR 작성

단일 목적을 충족하는 작고 집중적인 끌어오기 요청을 만드는 것을 목표로 합니다. 더 작은 끌어오기 요청은 더 쉽고 빠르게 검토 및 병합하고, 버그를 도입할 공간을 줄이고, 변경 내용의 보다 명확한 기록을 제공합니다.

먼저 사용자 고유의 끌어오기 요청 검토

제출하기 전에 사용자 고유의 끌어오기 요청을 검토, 빌드 및 테스트합니다. 이렇게 하면 다른 사용자가 검토를 시작하기 전에 누락되었을 수 있는 오류 또는 오타를 잡을 수 있습니다.

컨텍스트 및 참고 자료 제공

검토자가 끌어오기 요청이 수행하는 작업을 빠르게 이해할 수 있도록 끌어오기 요청에 대한 명확한 제목과 설명을 작성합니다. 끌어오기 요청 본문에 다음을 포함합니다.

• 끌어오기 요청의 목적
• 변경된 내용에 대한 개요
• 문제 추적 또는 이전 대화와 같은 추가 컨텍스트에 대한 링크

검토자를 돕기 위해 필요한 피드백 유형을 공유합니다. 예를 들어 빠른 보기 또는 심층 비판이 필요한가요?

끌어오기 요청이 여러 파일에 대한 변경 내용으로 구성된 경우 검토자에게 파일을 검토할 순서에 대한 지침을 제공합니다. 시작할 위치와 검토를 진행하는 방법을 권장합니다.

끌어오기 요청 관리 모범 사례

리포지토리 유지 관리자인 경우 기여자가 리포지토리에서 만드는 끌어오기 요청을 관리하고 표준화하려면 다음 단계를 수행합니다.

끌어오기 요청 템플릿 사용

끌어오기 요청 템플릿을 사용하면 리포지토리에서 끌어오기 요청을 만들 때 포함할 정보를 사용자 지정하고 표준화할 수 있습니다. 리포지토리에 끌어오기 요청 템플릿을 추가하면 프로젝트 기여자가 끌어오기 요청 본문에서 템플릿의 콘텐츠를 자동으로 볼 수 있습니다. 자세한 내용은 "리포지토리에 대한 끌어오기 요청 템플릿 만들기"을(를) 참조하세요.

끌어오기 요청 템플릿을 사용하여 리포지토리에 대한 검토 프로세스를 표준화할 수 있습니다. 예를 들어 템플릿에 작업 목록을 추가하여 끌어오기 요청을 병합하기 전에 작성자가 완료할 작업 목록을 포함할 수 있습니다. 자세한 내용은 "작업 목록 정보"을(를) 참조하세요.

끌어오기 요청을 병합하면 문제가 자동으로 닫히도록 기여자가 끌어오기 요청 본문에 문제 참조를 포함하도록 요청할 수 있습니다. 자세한 내용은 "끌어오기 요청을 이슈에 연결"을(를) 참조하세요.

코드 소유자 정의

특정 개인이 항상 리포지토리의 특정 코드 또는 파일에 대한 변경 내용을 검토하도록 할 수 있습니다. 예를 들어 팀의 기술 작성자가 docs 디렉터리의 변경 내용을 항상 검토하도록 할 수 있습니다.

리포지토리의 코드 또는 파일을 담당하는 개인 또는 팀을 코드 소유자로 정의할 수 있습니다. 코드 소유자는 자신이 소유한 파일을 수정하는 끌어오기 요청을 다른 사용자가 열 때 자동으로 검토 요청을 받습니다. 리포지토리의 여러 분기뿐만 아니라 특정 형식의 파일 또는 디렉터리에 대한 코드 소유자를 정의할 수 있습니다. 자세한 내용은 "코드 소유자 정보"을(를) 참조하세요.

보호된 분기 사용

보호된 분기를 사용하여 특정 조건이 충족될 때까지 끌어오기 요청이 중요한 분기(예: main)로 병합되는 것을 방지할 수 있습니다. 예를 들어 CI 테스트 또는 승인 검토를 통과해야 할 수 있습니다. 자세한 내용은 "보호된 분기 정보"을(를) 참조하세요.

푸시 규칙 집합 사용

푸시 규칙 집합을 사용하면 파일 확장명, 파일 경로 길이, 파일 및 폴더 경로, 파일 크기에 따라 프라이빗 또는 내부 리포지토리와 해당 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단할 수 있습니다.

푸시 규칙은 리포지토리에 대한 모든 푸시에 적용되므로 분기 대상 지정이 필요하지 않습니다.

푸시 규칙 집합을 사용하면 다음을 수행할 수 있습니다.

• 파일 경로 제한: 지정된 파일 경로의 변경 내용이 포함된 커밋이 푸시되지 않도록 합니다.

  이 테스트에 fnmatch 구문을 사용할 수 있습니다. 예를 들어 test/demo/**/*를 대상으로 하는 제한은 test/demo/ 디렉터리의 파일이나 폴더에 대한 푸시를 방지합니다. test/docs/pushrules.md를 대상으로 하는 제한 사항은 test/docs/ 디렉터리의 pushrules.md 파일에 대한 푸시를 방지합니다. 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기"을(를) 참조하세요.

• 파일 경로 길이 제한: 지정된 문자 제한을 초과하는 파일 경로가 포함된 커밋이 푸시되지 않도록 합니다.

• 파일 확장명 제한: 지정된 파일 확장명의 파일이 포함된 커밋이 푸시되지 않도록 합니다.

• 파일 크기 제한: 지정된 파일 크기 제한을 초과하는 커밋이 푸시되지 않도록 합니다.

포크된 리포지토리에 대한 푸시 규칙 집합 정보

푸시 규칙은 리포지토리의 전체 포크 네트워크에 적용되어 리포지토리에 대한 모든 진입점이 보호되도록 합니다. 예를 들어 푸시 규칙 집합을 사용하도록 설정된 리포지토리를 포크하는 경우 포크된 리포지토리에도 동일한 푸시 규칙 집합이 적용됩니다.

포크된 리포지토리의 경우 푸시 규칙에 대한 바이패스 권한이 있는 사람은 루트 리포지토리에서 바이패스 권한이 있는 사용자뿐입니다.

자세한 내용은 "규칙 세트 정보"을(를) 참조하세요.

자동화된 도구를 사용하여 코드 스타일 검토

리포지토리의 끌어오기 요청에서 linter와 같은 자동화된 도구를 사용하여 일관된 스타일을 유지하고 코드를 더 쉽게 이해할 수 있도록 합니다. 자동화된 도구를 사용하여 오타나 스타일 지정과 같은 작은 문제를 포착하면 검토자가 끌어오기 요청의 내용에 집중할 수 있는 시간이 더 늘어납니다.

예를 들어 GitHub Actions을(를) 사용하여 CI(연속 통합) 워크플로의 일부로 끌어오기 요청에서 실행할 수 있는 코드 linter를 설정할 수 있습니다. 자세한 내용은 "GitHub Actions를 사용한 연속 통합 정보" 항목을 참조하세요.