코드 배포

끌어오기 요청의 마지막 단계는 배포 분기에 대한 완료된 작업을 가져오는 것입니다. 이는 일반적으로 변경 내용을 릴리스 또는 주 분기로 병합하는 것을 의미합니다. 이렇게 하기 전에 변경 내용이 프로젝트의 요구 사항을 충족하는지 확인해야 합니다.

배포 전 점검 확인

병합하기 전에 변경 내용을 배포해도 안전한지 확인합니다. 상태 검사는 커밋이 연속 통합 빌드, 테스트, 코드 검사 또는 배포 검사와 같은 리포지토리에 대해 설정된 조건을 충족하는지 여부를 보여 줍니다. 풀 리퀘스트가 병합할 준비가 되었는지 여부를 귀하와 검토자가 파악하는 데 도움이 됩니다.

리포지토리에는 다음을 포함하여 끌어오기 요청이 병합되기 전에 특정 조건이 필요한 경우가 많습니다.

배포 파이프라인에서 실행하는 애플리케이션 상태 및 준비 상태 검사와 같이 통과해야 하는 필수 상태 검사입니다.
필수 검토 사항 또는 코드 소유자 승인
병합 충돌을 해결해야 합니다.

보호된 분기는 배포 분기가 안정적으로 유지되도록 이러한 요구 사항을 적용합니다.

모든 검사가 동일하지는 않습니다. GitHub Actions와 같은 제품이 생성한 풍부한 검사는 자세한 로그와 주석을 보고할 수 있는 반면, 더 단순한 커밋 상태는 다양한 연결 시스템에서 게시될 수 있습니다. 이를 이해하면 풀 리퀘스트가 준비되었는지 여부와 그 이유를 이해하는 데 도움이 됩니다.

릴리스 또는 메인 브랜치에 코드 병합

요구 사항이 충족되면 끌어오기 요청을 병합하여 해당 커밋을 기본 분기로 가져옵니다. 또한 요구 사항이 충족되는 즉시 끌어오기 요청이 병합되도록 병합을 자동화할 수 있습니다. 끌어오기 요청은 리포지토리 기록의 모양에 따라 다른 병합 전략을 제공합니다.

병합 커밋 은 끌어오기 요청 분기의 모든 커밋을 유지하고 명시적 병합 지점을 추가합니다.
Squash 및 Merge 는 모든 커밋을 단일 커밋으로 결합하여 간결한 기록을 만듭니다.
리베이스 및 병합은 병합 커밋 없이 선형 기록을 유지하면서 각 커밋을 기준 브랜치에 적용합니다.

최상의 전략은 팀이 보존하고자 하는 세부 사항에 따라 달라집니다.

대규모 요구 사항 적용

병합이 더 복잡해짐에 따라 팀은 병합을 안전하고 예측 가능하게 유지하기 위해 컨트롤을 추가합니다.

규칙 집합 및 브랜치 보호에서는 병합 전에 최신 상태의 브랜치, 서명된 커밋, 선형 히스토리 또는 특정 상태 검사를 요구할 수 있습니다.
병합 큐를 사용하면 트래픽이 많은 보호된 분기가 중단 없이 많은 끌어오기 요청을 수락할 수 있습니다. 기본 분기의 최신 버전에 대해 각 분기를 테스트하고 검사가 통과하면 순서대로 병합합니다. 분기에서 병합 큐를 사용하는 경우 사용 가능한 병합 옵션은 표준 병합과 다릅니다.

참고

Pull request 통합 큐는 GitHub Enterprise Server의 조직 소유 리포지토리에서 사용할 수 있습니다.

이 기사에서

배포 전 점검 확인

릴리스 또는 메인 브랜치에 코드 병합

대규모 요구 사항 적용

병합을 배포에 연결

병합 후 복구

병합되지 않는 끌어오기 요청 닫기

추가 읽기