끌어오기 요청의 마지막 단계는 배포 분기에 대한 완료된 작업을 가져오는 것입니다. 이는 일반적으로 변경 내용을 릴리스 또는 주 분기로 병합하는 것을 의미합니다. 이렇게 하기 전에 변경 내용이 프로젝트의 요구 사항을 충족하는지 확인해야 합니다.
배포 전 점검 확인
병합하기 전에 변경 내용을 배포해도 안전한지 확인합니다. 상태 검사는 커밋이 연속 통합 빌드, 테스트, 코드 검사 또는 배포 검사와 같은 리포지토리에 대해 설정된 조건을 충족하는지 여부를 보여 줍니다. 풀 리퀘스트가 병합할 준비가 되었는지 여부를 귀하와 검토자가 파악하는 데 도움이 됩니다.
리포지토리에는 다음을 포함하여 끌어오기 요청이 병합되기 전에 특정 조건이 필요한 경우가 많습니다.
- 배포 파이프라인에서 실행하는 애플리케이션 상태 및 준비 상태 검사와 같이 통과해야 하는 필수 상태 검사입니다.
- 필수 검토 사항 또는 코드 소유자 승인
- 병합 충돌을 해결해야 합니다.
보호된 분기는 배포 분기가 안정적으로 유지되도록 이러한 요구 사항을 적용합니다.
모든 검사가 동일하지는 않습니다. GitHub Actions와 같은 제품이 생성한 풍부한 검사는 자세한 로그와 주석을 보고할 수 있는 반면, 더 단순한 커밋 상태는 다양한 연결 시스템에서 게시될 수 있습니다. 이를 이해하면 풀 리퀘스트가 준비되었는지 여부와 그 이유를 이해하는 데 도움이 됩니다.
릴리스 또는 메인 브랜치에 코드 병합
요구 사항이 충족되면 끌어오기 요청을 병합하여 해당 커밋을 기본 분기로 가져옵니다. 또한 요구 사항이 충족되는 즉시 끌어오기 요청이 병합되도록 병합을 자동화할 수 있습니다. 끌어오기 요청은 리포지토리 기록의 모양에 따라 다른 병합 전략을 제공합니다.
- 병합 커밋 은 끌어오기 요청 분기의 모든 커밋을 유지하고 명시적 병합 지점을 추가합니다.
- Squash 및 Merge 는 모든 커밋을 단일 커밋으로 결합하여 간결한 기록을 만듭니다.
- 리베이스 및 병합은 병합 커밋 없이 선형 기록을 유지하면서 각 커밋을 기준 브랜치에 적용합니다.
최상의 전략은 팀이 보존하고자 하는 세부 사항에 따라 달라집니다.
대규모 요구 사항 적용
병합이 더 복잡해짐에 따라 팀은 병합을 안전하고 예측 가능하게 유지하기 위해 컨트롤을 추가합니다.
- 규칙 집합 및 브랜치 보호에서는 병합 전에 최신 상태의 브랜치, 서명된 커밋, 선형 히스토리 또는 특정 상태 검사를 요구할 수 있습니다.
- 병합 큐를 사용하면 트래픽이 많은 보호된 분기가 중단 없이 많은 끌어오기 요청을 수락할 수 있습니다. 기본 분기의 최신 버전에 대해 각 분기를 테스트하고 검사가 통과하면 순서대로 병합합니다. 분기에서 병합 큐를 사용하는 경우 사용 가능한 병합 옵션은 표준 병합과 다릅니다.
참고
Pull request 통합 큐는 조직이 소유한 모든 퍼블릭 리포지토리 또는 GitHub Enterprise Cloud을(를) 사용하는 조직이 소유한 프라이빗 리포지토리에서 사용할 수 있습니다. GitHub 계획을(를) 참조하세요.
병합을 배포에 연결
병합은 코드를 제공하는 트리거인 경우가 많습니다. GitHub Actions 는 끌어오기 요청이 릴리스 또는 주 분기에 병합될 때 배포 워크플로를 실행할 수 있습니다. 배포 환경은 배포 전 안전의 또 다른 계층을 추가합니다. 배포가 진행되기 전에 특정 검토자, 대기 타이머 또는 분기 제한이 필요할 수 있으며 다른 검사와 함께 표시됩니다.
병합 후 복구
체크 인이 있더라도 일부 병합은 실행 취소해야 합니다. 병합된 끌어오기 요청을 되돌려 변경 내용을 되돌리는 새 끌어오기 요청을 만들 수 있습니다. 유의하세요. 드문 경우지만, 끌어오기 요청의 커밋이 다른 경로를 통해 베이스 브랜치에 도달하면 해당 끌어오기 요청은 간접적으로 병합된 것으로 표시될 수 있습니다. 이렇게 하면 특정 끌어오기 요청에 대한 보호를 무시할 수 있습니다. 끌어오기 요청 되돌리기 및 끌어오기 요청 병합을(를) 참조하세요.
병합되지 않는 끌어오기 요청 닫기
모든 끌어오기 요청이 병합되어야 하는 것은 아닙니다. 변경이 더 이상 필요하지 않거나 다른 작업으로 대체되는 경우 병합하지 않고 끌어오기 요청을 닫을 수 있습니다. 닫는 것은 변경이 진행되지 않을 것임을 알리는 동시에 참조에 대한 토론과 기록을 유지합니다.
풀 리퀘스트가 병합되거나 닫히면 헤드 브랜치는 더 이상 필요하지 않은 경우가 많습니다. 사용되지 않는 분기를 삭제하면 리포지토리를 더 쉽게 탐색할 수 있습니다.