머지 리퀘스트는 팀이 코드를 리뷰하고, 논의하고, 코드 변경 사항을 추적할 수 있는 중앙 위치를 제공합니다. 변경이 이루어진 이유를 설명하려면 머지 리퀘스트를 이슈와 연결하고 머지 리퀘스트가 머지될 때 이슈가 자동으로 닫히도록 합니다.

머지 리퀘스트는 주제 전문가가 제안된 변경 사항을 리뷰하고 조직의 보안 요구 사항이 충족되도록 하는 데 도움이 됩니다. 개발 프로세스 초기에 머지 리퀘스트를 생성하면 팀이 버그와 코드 품질 문제를 잡아낼 시간을 확보합니다.

머지 리퀘스트를 볼 때 다음이 표시됩니다:

• 리퀘스트에 대한 설명.
• 코드 변경 사항과 인라인 코드 리뷰.
• CI/CD 파이프라인에 대한 정보.
• 머지 가능성 보고서.
• 댓글.
• 커밋 목록.

담당자와 리뷰어#

머지 리퀘스트에는 두 가지 역할이 있습니다:

• Assignee: 머지 리퀘스트를 소유하고 그 진행을 책임집니다. 담당자는 보통 작성자입니다.
• Reviewer: 변경 사항을 리뷰하고 피드백을 제공합니다. 리뷰어는 변경을 요청할 수 있고, 자격이 있으면 머지 리퀘스트를 승인할 수 있습니다.

프로젝트의 승인 규칙 및 설정이 누가 머지 리퀘스트를 승인할 수 있는지를 결정합니다.

자세한 내용은 담당자 할당과 리뷰어 요청을 참고합니다.

머지 리퀘스트 생성#

머지 리퀘스트를 생성하는 여러 방법을 알아봅니다.

머지 리퀘스트 템플릿 사용#

머지 리퀘스트를 생성하면 GitLab은 머지 리퀘스트에 데이터를 추가할 설명 템플릿이 있는지 확인합니다. GitLab은 1부터 5까지 순서대로 다음 위치를 확인하고, 가장 먼저 찾은 템플릿을 머지 리퀘스트에 적용합니다:

머지 리퀘스트 보기#

프로젝트, 그룹 또는 자신의 머지 리퀘스트를 볼 수 있습니다.

머지 리퀘스트 목록의 RSS 피드 구독#

프로젝트 머지 리퀘스트 목록의 RSS 피드를 구독하려면 다음과 같이 진행합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
3. 오른쪽 위 모서리에서 Actions (⋮) > Subscribe to RSS feed를 선택합니다.

그룹 머지 리퀘스트 목록의 RSS 피드를 구독할 때도 같은 단계를 따릅니다. 상단 바에서 Search or go to를 선택하고 프로젝트가 아니라 그룹을 찾습니다.

피드 URL에는 사용자를 피드 리더로 인증하는 피드 토큰이 포함되어 있습니다.

머지 리퀘스트 목록 필터링#

히스토리

• merged by 필터가 GitLab 16.9에서 도입되었습니다. 기능 플래그 mr_merge_user_filter가 활성화된 경우에만 사용할 수 있습니다.
• merged by 필터가 GitLab 17.0에서 일반 사용 가능해졌습니다. 기능 플래그 mr_merge_user_filter가 제거되었습니다.
• merged before 및 merged after 필터가 GitLab 18.6에서 도입되었습니다.

머지 리퀘스트 목록을 필터링하려면 다음과 같이 진행합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택합니다.
3. 머지 리퀘스트 목록 위에서 Search or filter results를 선택합니다.
4. 드롭다운 목록에서 필터링할 속성을 선택합니다. 예를 들면 다음과 같습니다:
   • By environment or deployment date.
   • ID: 필터 #30을 입력하면 머지 리퀘스트 30만 반환됩니다.
   • 사용자 필터:
     • Approved by: 사용자가 이미 승인한 머지 리퀘스트입니다. Premium 및 Ultimate 전용.
     • Approver: 이 사용자가 승인할 자격이 있는 머지 리퀘스트입니다. (자세한 내용은 코드 소유자를 참고합니다.) Premium 및 Ultimate 전용.
     • Merged by: 이 사용자가 머지한 머지 리퀘스트입니다.
     • Reviewer: 이 사용자가 리뷰한 머지 리퀘스트입니다.
5. 속성을 필터링할 때 사용할 연산자를 선택하거나 입력합니다. 사용할 수 있는 연산자는 다음과 같습니다:
   • =: Is
   • !=: Is not
6. 속성을 필터링할 텍스트를 입력합니다. 일부 속성은 None 또는 Any로 필터링할 수 있습니다.
7. 이 과정을 반복하여 속성을 더 추가해 필터링합니다. 추가한 속성은 논리 AND로 연결됩니다.
8. Sort direction을 선택합니다. 내림차순은 [sort-lowest], 오름차순은 [sort-highest] 입니다.

환경 또는 배포 날짜 기준#

환경이나 날짜와 같은 배포 데이터로 머지 리퀘스트를 필터링하려면 다음을 입력하거나 드롭다운 목록에서 선택할 수 있습니다:

• Environment
• Deployed before
• Deployed after

환경으로 필터링하려면 사용할 수 있는 환경 드롭다운 목록에서 옵션을 선택합니다.

Deployed before 또는 Deployed after로 필터링하려면 배포 날짜를 직접 입력합니다:

• 이 날짜는 (머지 커밋으로 트리거된) 환경 배포가 성공적으로 완료된 시점을 가리킵니다.
• YYYY-MM-DD 형식을 사용합니다. 날짜와 시간을 함께 지정하려면 큰따옴표를 사용합니다("YYYY-MM-DD HH:MM").

머지 리퀘스트에 변경 사항 추가#

머지 리퀘스트에 변경 사항을 추가할 권한이 있으면 여러 방법으로 추가할 수 있습니다. 어떤 방법을 사용할지는 변경의 복잡도와 개발 환경에 액세스해야 하는지 여부에 따라 달라집니다:

• 브라우저에서 Web IDE로 변경 사항 편집. GitLab의 아무 프로젝트 페이지에서 .(마침표)를 누르면 Web IDE가 열립니다. 여러 파일을 편집하거나 Git 명령에 익숙하지 않은 경우 이 브라우저 기반 방법을 사용합니다. Web IDE에서는 테스트를 실행할 수 없습니다.
• 파일을 편집하고 이어서 테스트까지 실행할 수 있는 완전한 기능의 환경이 필요하면 Ona에서 변경 사항 편집. Ona는 GitLab Development Kit(GDK)을 지원합니다. Ona를 사용하려면 사용자 계정에서 Ona를 켜야 합니다.
• Git과 명령줄에 익숙하면 명령줄에서 변경 사항 푸시를 사용합니다.

머지 리퀘스트에 사용자 할당#

머지 리퀘스트에 사용자를 할당하려면 머지 리퀘스트의 텍스트 영역에서 /assign @user 빠른 작업을 사용하거나, 다음과 같이 진행합니다:

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

2. 왼쪽 사이드바에서 Code > Merge requests를 선택하고 머지 리퀘스트를 찾습니다.

3. 오른쪽 사이드바의 Assignees 섹션에서 Edit를 선택합니다.

4. 할당할 사용자를 검색해 선택합니다. GitLab Free에서는 머지 리퀘스트당 사용자 한 명을 할당할 수 있습니다. GitLab Premium과 GitLab Ultimate에서는 여러 사용자를 할당할 수 있습니다:

   

GitLab은 해당 사용자의 Assigned merge requests 페이지에 머지 리퀘스트를 추가합니다.

참여자#

참여자는 머지 리퀘스트와 상호작용한 사용자입니다. 참여자 보기에 대한 자세한 내용은 참여자를 참고합니다.

머지 리퀘스트 머지#

머지 리퀘스트 리뷰 과정에서 리뷰어는 변경 사항에 대한 피드백을 제공합니다. 리뷰어가 변경 사항에 만족하면 일부 머지 검사가 실패하고 있더라도 머지 리퀘스트를 자동 머지로 설정할 수 있습니다. 모든 머지 검사를 통과하면 머지 리퀘스트는 추가 조치 없이 자동으로 머지됩니다.

기본 머지 권한:

• 기본 브랜치(일반적으로 main)는 보호됩니다.
• Maintainer 이상의 권한만 기본 브랜치에 머지할 수 있습니다.
• Developer는 보호되지 않은 브랜치를 대상으로 하는 모든 머지 리퀘스트를 머지할 수 있습니다.

특정 머지 리퀘스트를 머지할 권한이 있는지 판단하기 위해 GitLab은 다음을 확인합니다:

• 프로젝트에서의 권한. 예를 들어 Developer, Maintainer, Owner 입니다.
• 대상 브랜치의 브랜치 보호 설정.

머지 리퀘스트 닫기#

머지 리퀘스트 작업을 영구적으로 중단하기로 결정했다면 삭제하는 대신 닫습니다.

사전 요구 사항:

• 머지 리퀘스트의 작성자나 담당자여야 하거나, 프로젝트에 대한 Developer, Maintainer, Owner 권한이 있어야 합니다.

프로젝트에서 머지 리퀘스트를 닫으려면 다음과 같이 진행합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택하고 머지 리퀘스트를 찾습니다.
3. 페이지 아래쪽의 댓글 상자로 스크롤합니다.
4. 댓글 상자 다음에서 Close merge request를 선택합니다.

GitLab은 머지 리퀘스트를 닫지만 머지 리퀘스트와 그 댓글, 연결된 파이프라인의 기록은 보존합니다.

소스 브랜치 삭제#

히스토리

• 닫힌 머지 리퀘스트에서 소스 브랜치를 삭제하는 옵션이 GitLab 19.1에서 도입되었습니다.

머지 리퀘스트의 소스 브랜치를 삭제하는 방법은 다음과 같습니다:

• 머지 리퀘스트를 생성할 때 Delete source branch when merge request accepted를 선택합니다.
• 머지 리퀘스트를 머지할 때 Maintainer 권한이 있으면 Delete source branch를 선택합니다.
• 머지하지 않고 머지 리퀘스트를 닫을 때 Delete source branch를 선택합니다.

관리자는 프로젝트 설정에서 이 옵션을 기본값으로 지정할 수 있습니다. 포크에서 생성된 머지 리퀘스트의 경우 GitLab은 대상 프로젝트가 아니라 포크에서 Delete source branch 기본값을 읽습니다.

브랜치 삭제는 자동 머지를 설정하거나 머지 리퀘스트를 머지한 사용자가 수행합니다. 포크 프로젝트처럼 그 사용자에게 올바른 권한이 없으면 소스 브랜치 삭제가 실패합니다.

대상 브랜치가 머지될 때 머지 리퀘스트 업데이트#

머지 리퀘스트는 하나의 머지 리퀘스트가 다른 머지 리퀘스트에서 추가하거나 변경한 코드에 의존하는 형태로 서로 연결되는 경우가 많습니다. 작고 개별적인 머지 리퀘스트를 지원하기 위해 GitLab은 대상 브랜치가 main에 머지될 때 열려 있는 머지 리퀘스트를 최대 네 개까지 업데이트할 수 있습니다. 예를 들면 다음과 같습니다:

• 머지 리퀘스트 1: feature-alpha를 main에 머지.
• 머지 리퀘스트 2: feature-beta를 feature-alpha에 머지.

이 머지 리퀘스트들이 동시에 열려 있고 머지 리퀘스트 1(feature-alpha)이 main에 머지되면, GitLab은 머지 리퀘스트 2의 대상을 feature-alpha에서 main으로 업데이트합니다.

내용이 서로 얽힌 머지 리퀘스트는 보통 다음 중 한 가지 방식으로 처리됩니다:

• 머지 리퀘스트 1 이 먼저 main에 머지됩니다. 그 다음 머지 리퀘스트 2의 대상이 main으로 변경됩니다.
• 머지 리퀘스트 2가 feature-alpha에 머지됩니다. feature-alpha와 feature-beta의 내용을 모두 담은 머지 리퀘스트 1 이 main에 머지됩니다.

이 기능은 머지 리퀘스트가 머지될 때만 동작합니다. 머지 후 Remove source branch를 선택하는 것으로는 열려 있는 머지 리퀘스트의 대상이 변경되지 않습니다. 이 개선은 후속 작업으로 제안되어 있습니다.

머지 리퀘스트 워크플로#

팀에서 일하는 소프트웨어 개발자의 경우:

1. 새 브랜치를 체크아웃하고 머지 리퀘스트로 변경 사항을 제출합니다.
2. 팀에서 피드백을 수집합니다.
3. 코드 품질 보고서로 코드를 최적화합니다.
4. GitLab CI/CD의 단위 테스트 보고서로 변경 사항을 검증합니다.
5. 라이선스 승인 정책으로 프로젝트와 호환되지 않는 라이선스를 가진 의존성을 피합니다.
6. 매니저에게 승인을 요청합니다.
7. 매니저는 다음을 수행합니다:
   1. 최종 리뷰와 함께 커밋을 푸시합니다.
   2. 머지 리퀘스트를 승인합니다.
   3. 머지 리퀘스트를 자동 머지(이전 이름 Merge when pipeline succeeds)로 설정합니다.
8. GitLab CI/CD의 수동 job으로 변경 사항이 프로덕션에 배포됩니다.
9. 구현이 고객에게 전달됩니다.

회사 웹사이트의 웹 페이지를 작성하는 웹 개발자의 경우:

1. 새 브랜치를 체크아웃하고 머지 리퀘스트로 새 페이지를 제출합니다.
2. 리뷰어에게서 피드백을 수집합니다.
3. 리뷰 앱으로 변경 사항을 미리 봅니다.
4. 웹 디자이너에게 디자이너의 변경 사항을 구현해 달라고 요청합니다.
5. 매니저에게 승인을 요청합니다.
6. 승인 후 GitLab은 다음을 수행합니다:
   • 커밋을 스쿼시합니다.
   • 커밋을 머지합니다.
   • GitLab Pages로 스테이징에 변경 사항을 배포합니다.
7. 프로덕션 팀이 머지 커밋을 프로덕션으로 체리픽합니다.

머지 리퀘스트의 활동 필터링#

머지 리퀘스트의 이력을 파악하려면 활동 피드를 필터링해 자신에게 관련된 항목만 표시합니다.

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

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

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

4. Activity로 스크롤합니다.

5. 페이지 오른쪽에서 Activity filter를 선택하여 필터 옵션을 표시합니다. 이미 필터 옵션을 선택했다면 이 필드에는 Activity + 5 more처럼 선택 내용을 요약해 보여 줍니다.

6. 보려는 활동 유형을 선택합니다. 옵션에는 다음이 있습니다:

   • Assignees & Reviewers
   • Approvals
   • Comments (from bots)
   • Comments (from users)
   • Commits & branches
   • Edits
   • Labels
   • Lock status
   • Mentions
   • Merge request status
   • Tracking

7. 선택 사항. Sort ([sort-lowest])를 선택하여 정렬 순서를 반대로 바꿉니다.

선택한 내용은 모든 머지 리퀘스트에 계속 적용됩니다. 오른쪽의 정렬 버튼으로 정렬 순서를 변경할 수도 있습니다.

댓글 스레드 관리#

머지 리퀘스트의 논의는 단일 댓글과 댓글 스레드로 구성됩니다. 열린(해결되지 않은) 스레드는 머지 리퀘스트의 머지를 차단하지만 단일 댓글은 차단하지 않습니다. 스레드의 논의가 끝나면 스레드를 해결하여 표시를 접습니다. 댓글 스레드가 중요하지만 머지 리퀘스트를 차단해서는 안 된다면, 논의를 이어가기 위해 이슈로 옮깁니다.

모든 스레드 확장#

GitLab은 머지 리퀘스트의 오른쪽 위 모서리에 열린 스레드 수를 표시합니다. 이 머지 리퀘스트에는 열린 스레드가 세 개 있습니다:

접힌 스레드의 모든 댓글을 보려면 스레드를 확장합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Code > Merge requests를 선택하고 머지 리퀘스트를 찾습니다.
3. 머지 리퀘스트의 오른쪽 위에서 Open threads 드롭다운 목록을 찾고 Thread options (⋮)를 선택합니다.
4. Show all comments를 선택합니다.

열린 스레드를 이슈로 옮기기#

열린 스레드를 새 이슈로 옮겨 머지 리퀘스트의 차단을 해제하려면 다음과 같이 진행합니다:

모든 스레드가 해결되기 전에는 머지 차단#

스레드가 열려 있는 동안 머지 리퀘스트가 머지되지 않도록 할 수 있습니다. 이 설정을 켜면 스레드가 하나라도 열려 있는 동안 머지 리퀘스트의 Open threads 카운터가 주황색으로 표시됩니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. Merge checks 섹션에서 All threads must be resolved 체크박스를 선택합니다.
4. Save changes를 선택합니다.

스레드가 오래되면 자동으로 해결#

새 푸시가 스레드가 설명하는 줄을 변경할 때 스레드를 자동으로 해결하도록 머지 리퀘스트를 구성할 수 있습니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. Merge options 섹션에서 Automatically resolve merge request diff threads when they become outdated를 선택합니다.
4. Save changes를 선택합니다.

이제 푸시로 diff 섹션이 오래된 상태가 되면 스레드가 해결됩니다. 변경되지 않은 줄의 스레드와 최상위 수준의 해결 가능한 스레드는 해결되지 않습니다.

알림과 할 일 항목 이동#

히스토리

• GitLab 16.5에서 notifications_todos_buttons라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• 이슈, 인시던트와 에픽도 함께 업데이트되었습니다.
• GitLab 19.3에서 일반 사용 가능해졌습니다. 기능 플래그 notifications_todos_buttons가 제거되었습니다.

알림 버튼과 할 일 항목 버튼은 페이지 오른쪽 위 모서리에 표시됩니다.

• 머지 리퀘스트에서는 이 버튼들이 탭의 가장 오른쪽에 표시됩니다.
• 이슈, 인시던트, 에픽에서는 이 버튼들이 오른쪽 사이드바 위쪽에 표시됩니다.

관련 주제#

• 리포지터리 보호
• 머지 리퀘스트 리뷰
• 스택된 머지 리퀘스트
• 머지 리퀘스트 인가
• 테스트 및 보고서
• 댓글 및 스레드
• 코드 변경 제안
• CI/CD 파이프라인
• 머지 리퀘스트용 푸시 옵션
• 머지 리퀘스트 제목 유효성 검사