머지 리퀘스트의 내용이 병합할 준비가 되었다면 Set to auto-merge를 선택할 수 있습니다. 필수 검사가 모두 성공적으로 완료되면 머지 리퀘스트가 자동으로 병합되므로, 머지 리퀘스트를 수동으로 병합할 시점을 기억할 필요가 없습니다.

머지 검사를 사용하면 머지 리퀘스트의 내용 검토에 집중하고, 병합 가능 여부는 프로젝트 설정으로 판단할 수 있습니다. 머지 리퀘스트를 검토하고 변경 사항에 동의한다면 자동 머지로 설정합니다. GitLab은 프로젝트 설정을 강제 적용하며, 머지 리퀘스트가 모든 머지 검사(필수 Code Owner 규칙, 승인 규칙 등)를 충족할 때까지 병합되지 않습니다. 필수 머지 검사를 모두 충족하면 별도의 조치 없이 머지 리퀘스트가 병합됩니다.

머지 검사에는 CI/CD 파이프라인 통과를 포함해 다음 항목이 있습니다.

• 필수 승인이 모두 이루어져야 합니다.
• 이 머지 리퀘스트를 차단하는 다른 머지 리퀘스트가 없어야 합니다.
• 머지 충돌이 없어야 합니다.
• 프로젝트 설정과 관계없이 CI/CD 파이프라인이 성공적으로 완료되어야 합니다.
• 모든 토론이 해결되어야 합니다.
• 머지 리퀘스트가 Draft 상태가 아니어야 합니다.
• 모든 외부 상태 검사를 통과해야 합니다.
• 머지 리퀘스트가 열려 있어야 합니다.
• 거부된 정책이 없어야 합니다.
• 스캔 실행 정책 또는 파이프라인 실행 정책이 구성된 경우, 머지 리퀘스트가 병합되기 전에 최신 커밋의 모든 파이프라인이 성공해야 합니다.
• 프로젝트가 머지 리퀘스트에 Jira 이슈 참조를 요구하는 경우, 머지 리퀘스트 제목이나 설명에 Jira 이슈 링크가 있어야 합니다.
• 제목 검증 패턴이 구성된 경우, 머지 리퀘스트 제목이 해당 패턴과 일치해야 합니다.
• 머지 리퀘스트에 Merge after 날짜가 설정된 경우, 현재 시각이 설정된 날짜 이후여야 합니다.

검사 항목 전체 목록과 이에 대응하는 API 값은 머지 상태를 참고합니다.

자동 머지를 설정한 다음에는 머지 리퀘스트가 병합될 때 자동으로 닫힐 이슈를 변경할 수 없습니다.

머지 리퀘스트 자동 머지#

사전 요건:

• 프로젝트에 대한 Developer, Maintainer, Owner 권한 중 하나가 있어야 합니다.
• 프로젝트 구성에서 요구하는 경우, 머지 리퀘스트의 모든 스레드가 해결되어야 합니다.
• 머지 리퀘스트가 필수 승인을 모두 받아야 합니다.

명령줄에서 푸시할 때 이 작업을 하려면 merge_request.merge_when_pipeline_succeeds 푸시 옵션을 사용합니다.

GitLab 사용자 인터페이스에서 이 작업을 하려면 다음 단계를 따릅니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.

3. 편집할 머지 리퀘스트를 선택합니다.

4. 머지 리퀘스트 리포트 섹션으로 스크롤합니다.

5. 선택 사항. Delete source branch, Squash commits, Edit commit message 등 원하는 머지 옵션을 선택합니다.

6. 머지 리퀘스트 리포트 섹션의 내용을 검토합니다. 이슈 닫기 패턴이 포함되어 있다면, 머지 리퀘스트가 병합될 때 해당 이슈가 닫혀야 하는지 확인합니다.

   

7. Set to auto-merge를 선택합니다.

자동 머지로 설정한 뒤 파이프라인이 완료되기 전에 머지 리퀘스트에 댓글을 남기면, 기존 스레드를 모두 해결할 때까지 병합이 차단됩니다.

자동 머지 취소#

머지 리퀘스트의 자동 머지를 취소할 수 있습니다.

사전 요건:

• 머지 리퀘스트 작성자이거나, Developer, Maintainer, Owner 권한 중 하나를 가진 프로젝트 멤버여야 합니다.
• 머지 리퀘스트의 파이프라인이 아직 진행 중이어야 합니다.

다음 단계를 따릅니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
3. 원하는 머지 리퀘스트를 선택합니다.
4. 머지 리퀘스트 리포트 섹션으로 스크롤합니다.
5. Cancel auto-merge를 선택합니다.

자동 머지를 위한 파이프라인 성공#

파이프라인이 성공하면 머지 리퀘스트가 병합됩니다. 파이프라인이 실패하면 작성자는 실패한 job을 다시 실행하거나, 실패를 해결하는 새 커밋을 푸시할 수 있습니다.

• 다시 실행한 job이 두 번째 시도에서 성공하면 머지 리퀘스트가 병합됩니다.
• 머지 리퀘스트에 새 커밋을 추가하면, 병합 전에 새 변경 사항이 검토되도록 GitLab이 요청을 취소합니다.
• 대상 브랜치에 새 커밋을 추가했고 프로젝트가 병합 전 자동 리베이스를 켜지 않은 채 Merge commit with semi-linear history 또는 Fast-forward merge 방식을 사용하는 경우, GitLab은 머지 충돌을 방지하기 위해 요청을 취소합니다. 병합 전 자동 리베이스를 켠 경우에는 자동 머지가 유지되며, 머지 리퀘스트가 병합될 때 GitLab이 리베이스합니다.

파이프라인 상태를 더 엄격하게 제어하려면 병합 전에 성공한 파이프라인을 요구할 수도 있습니다.

병합을 위한 성공적인 파이프라인 필요#

병합 전에 파이프라인이 완료되고 성공하도록 프로젝트를 구성할 수 있습니다. 이 구성은 다음 두 가지 모두에 적용됩니다.

• GitLab CI/CD 파이프라인.
• 외부 CI 통합에서 실행되는 파이프라인.

따라서 GitLab CI/CD 파이프라인을 비활성화해도 이 기능은 비활성화되지 않으며, 외부 CI 공급자의 파이프라인을 함께 사용할 수 있습니다.

사전 요건:

• 프로젝트의 CI/CD 구성이 모든 머지 리퀘스트에 대해 파이프라인을 실행하는지 확인합니다.
• 프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.

이 설정을 활성화하려면 다음 단계를 따릅니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. Merge checks로 스크롤한 다음 Pipelines must succeed를 선택합니다. 이 설정은 파이프라인이 없는 경우에도 머지 리퀘스트 병합을 막으며, 이로 인해 일부 규칙과 충돌할 수 있습니다.
4. Save를 선택합니다.

같은 머지 리퀘스트에서 여러 파이프라인 유형이 실행되면 머지 리퀘스트 파이프라인이 다른 파이프라인 유형보다 우선합니다. 예를 들어 더 최근이지만 실패한 브랜치 파이프라인이 있더라도, 더 오래되었지만 성공한 머지 리퀘스트 파이프라인이 있으면 머지 리퀘스트를 병합할 수 있습니다.

마찬가지로 프로젝트와 함께 가져온 파이프라인은 원본 상태를 유지하며, 대상에서 실행하지 않아도 이 검사를 충족할 수 있습니다. 가져온 머지 리퀘스트는 병합하기 전에 새 파이프라인을 실행합니다.

스킵된 파이프라인 후 병합 허용#

프로젝트에 Pipelines must succeed를 설정하면 스킵된 파이프라인이 있을 때 머지 리퀘스트가 병합되지 않습니다.

사전 요건:

• 프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.

이 동작을 변경하려면 다음 단계를 따릅니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. Merge checks 아래에서 다음을 수행합니다.
   • Pipelines must succeed를 선택합니다.
   • Skipped pipelines are considered successful를 선택합니다.
4. Save를 선택합니다.

특정 날짜 이전 병합 방지#

머지 리퀘스트가 특정 날짜와 시각 이전에 병합되지 않아야 한다면 Merge can start 날짜를 설정합니다. 이 값은 병합(또는 머지 트레인)을 시작할 수 있는 시점을 지정합니다. 다만 실제 병합 시각은 다른 머지 검사의 충족 여부나 머지 트레인의 길이에 따라 달라질 수 있습니다.

사전 요건:

• 프로젝트에 대한 Developer, Maintainer, Owner 권한 중 하나가 있어야 합니다.

다음 단계를 따릅니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
3. 편집할 머지 리퀘스트를 선택합니다.
4. Edit를 선택합니다.
5. Merge can start 드롭다운 목록에서 After scheduled date를 선택한 다음, 날짜와 시각을 선택합니다.
6. Save changes를 선택합니다.

문제 해결#

실패한 파이프라인이 없는데도 머지 리퀘스트 병합 불가#

병합을 위한 성공적인 파이프라인을 요구했는데, 실패한 파이프라인이 없는데도 머지 리퀘스트를 병합하지 못하는 경우가 있습니다. 이 설정은 실패한 파이프라인이 없을 것이 아니라 성공한 파이프라인이 있을 것을 요구합니다. 파이프라인이 아예 없는 머지 리퀘스트는 성공한 파이프라인이 있는 것으로 보지 않으므로 병합되지 않습니다.

이 설정을 활성화할 때는 rules 또는 workflow:rules를 사용해 모든 머지 리퀘스트에서 파이프라인이 실행되도록 합니다.

실패한 파이프라인에도 불구하고 머지 리퀘스트 병합 가능#

병합을 위한 성공적인 파이프라인을 요구했는데도 파이프라인이 실패한 머지 리퀘스트가 병합되는 경우가 있습니다.

Pipelines must succeed 설정에서는 머지 리퀘스트 파이프라인의 우선순위가 가장 높습니다. 같은 머지 리퀘스트에서 여러 파이프라인 유형이 실행되면 GitLab은 머지 리퀘스트 파이프라인의 성공 여부만 확인합니다.

다음과 같은 경우 머지 리퀘스트에 여러 파이프라인이 있을 수 있습니다.

• 중복 파이프라인을 유발하는 rules 구성으로 머지 리퀘스트 파이프라인 하나와 브랜치 파이프라인 하나가 생기는 경우입니다. 이때는 브랜치 파이프라인이 아니라 최신 머지 리퀘스트 파이프라인의 상태가 병합 가능 여부를 결정합니다.
• 외부 도구가 머지 리퀘스트와 같은 브랜치를 대상으로 트리거한 파이프라인이 있는 경우입니다.

어느 경우든 같은 머지 리퀘스트에서 여러 파이프라인 유형이 실행되지 않도록 CI/CD 구성을 수정합니다.