# 코드 배포

배포 전 검사의 유효성을 검사하고, 병합 전략을 선택하고, 코드를 배포할 때 분기를 효과적으로 관리합니다.

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

## 배포 전 점검 확인

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

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

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

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

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

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

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

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

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

## 대규모 요구 사항 적용

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

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

> \[!NOTE]
>
> Pull request 통합 큐는 조직이 소유한 모든 퍼블릭 리포지토리 또는 GitHub Enterprise Cloud을(를) 사용하는 조직이 소유한 프라이빗 리포지토리에서 사용할 수 있습니다. [GitHub 계획](/ko/get-started/learning-about-github/githubs-plans)을(를) 참조하세요.

## 병합을 배포에 연결

병합은 코드를 제공하는 트리거인 경우가 많습니다.
GitHub Actions 는 끌어오기 요청이 릴리스 또는 주 분기에 병합될 때 배포 워크플로를 실행할 수 있습니다.
**배포 환경은** 배포 전 안전의 또 다른 계층을 추가합니다. 배포가 진행되기 전에 특정 검토자, 대기 타이머 또는 분기 제한이 필요할 수 있으며 다른 검사와 함께 표시됩니다.

## 병합 후 복구

체크 인이 있더라도 일부 병합은 실행 취소해야 합니다. 병합된 끌어오기 요청을 되돌려 변경 내용을 되돌리는 새 끌어오기 요청을 만들 수 있습니다. 유의하세요. 드문 경우지만, 끌어오기 요청의 커밋이 다른 경로를 통해 베이스 브랜치에 도달하면 해당 끌어오기 요청은 *간접적으로* 병합된 것으로 표시될 수 있습니다. 이렇게 하면 특정 끌어오기 요청에 대한 보호를 무시할 수 있습니다.
[끌어오기 요청 되돌리기](/ko/pull-requests/how-tos/merge-and-close-pull-requests/reverting-a-pull-request) 및 [끌어오기 요청 병합](/ko/pull-requests/reference/pull-request-merges#indirect-merges)을(를) 참조하세요.

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

모든 끌어오기 요청이 병합되어야 하는 것은 아닙니다. 변경이 더 이상 필요하지 않거나 다른 작업으로 대체되는 경우 병합하지 않고 끌어오기 요청을 닫을 수 있습니다. 닫는 것은 변경이 진행되지 않을 것임을 알리는 동시에 참조에 대한 토론과 기록을 유지합니다.

풀 리퀘스트가 병합되거나 닫히면 헤드 브랜치는 더 이상 필요하지 않은 경우가 많습니다. 사용되지 않는 분기를 삭제하면 리포지토리를 더 쉽게 탐색할 수 있습니다.

## 추가 읽기

* [Merging a pull request](/ko/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request)
* [Status checks](/ko/pull-requests/reference/status-checks)
* [배포 환경 관리](/ko/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)