Merge Request 기능

소스 브랜치에서 타깃 브랜치로 변경 사항을 통합하기 위해 Merge Request(MR)를 사용합니다.

Merge Request를 열면 merge 하기 전에 변경 사항을 시각화하고 협업할 수 있습니다. Merge Request는 다음 사항을 포함합니다.

• 요청 사항 설명
• 코드 변경 사항과 인라인 코드 리뷰
• CI/CD 파이프라인 정보
• 토론 스레드의 코멘트 섹션
• 커밋 목록

Merge Request 생성하기

Merge Request를 생성하는 다양한 방법을 학습하세요.

Merge Request 템플릿 사용하기

Merge Request를 생성하면 GitLab은 Merge Request에 데이터를 추가하기 위해 설명 템플릿 유무를 확인합니다. GitLab은 1~5번 순서로 이 위치를 확인하고, 가장 먼저 발견한 템플릿을 Merge Request에 적용합니다.

이름	프로젝트 UI 설정	그룹 default.md	인스턴스 default.md	프로젝트 default.md	템플릿 없음
표준 커밋 메시지	1	2	3	4	5
Closes #1234와 같은 이슈 닫기 패턴이 있는 커밋 메시지	1	2	3	4	5*
1234-example과 같이 issue ID가 앞에 붙은 브랜치 이름	1*	2*	3*	4*	5*

참고

별표(*)가 표시된 항목은 이슈 닫기 패턴을 추가합니다.

Merge Request 보기

프로젝트, 그룹, 개인의 Merge Request를 볼 수 있습니다.

프로젝트

프로젝트의 모든 Merge Request를 보려면

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
2. Code > Merge requests를 클릭합니다.

또는 키보드 단축키를 사용하려면 g + m을 누릅니다.

그룹의 모든 프로젝트

그룹에서 모든 프로젝트의 Merge Request를 보려면

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 그룹을 찾습니다.
2. Code > Merge requests를 클릭합니다.

그룹에 하위 그룹이 있으면, 이 보기는 하위 그룹 프로젝트에서 Merge Request를 표시합니다.

나에게 할당됨

나에게 할당된 모든 Merge Request를 보려면

1. 왼쪽 사이드바에서 Search or go to를 클릭합니다.
2. 드롭다운 목록에서 Merge requests assigned to me를 클릭합니다.

또는

• 키보드 단축키를 사용하려면, Shift+m을 누릅니다.

또는

1. 왼쪽 사이드바에서 Code>Merge requests를 클릭합니다.
2. 드롭다운 목록에서 Assigned를 클릭합니다.

Merge Request 목록을 필터링하기

• GitLab 13.0에 도입된 approved-by별 필터링
  
• GitLab 13.7에 도입된 reviewer별 필터링
  
• 잠재적 승인자별 필터링이 GitLab 13.9에서 GitLab Premium 기능으로 이동했습니다.
  
• approved-by별 필터링이 GitLab 13.9에서 GitLab Premium 기능으로 이동했습니다.
• source-branch별 필터링이 GitLab 16.6에 도입됐습니다.

Merge Request의 목록을 필터링하려면

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
2. Code > Merge requests를 클릭합니다.
3. Merge Request 목록 위에, **Search or filter results...**를 클릭합니다.
4. 드롭다운 목록에서 필터링하려는 속성을 선택합니다. 예를 들어,
   • environment or deployment date(환경 또는 배포 날짜)
   • ID: Merge Request 30만 반환하려면 필터 #30을 입력하기
   • User filter(사용자 필터): 사용자 목록을 표시하려면 다음 필터 중 하나를 입력하기(또는 드롭다운 목록에서 선택하기)
     • Approved-By: 사용자가 이미 승인한 Merge Request일 때(Premium)
     • Approver: 사용자가 승인할 자격이 있는 Merge Request일 때(더 자세한 정보는 Code owners를 참조하세요).(Premium)
     • Reviewer: 이 사용자가 리뷰한 Merge Request일 때
5. 속성을 필터링하는 데 사용할 연산자를 선택하거나 입력합니다. 다음 연산자를 사용할 수 있습니다.
   • =: Is
   • !=: Is not
6. 속성을 필터링할 텍스트를 입력합니다. None 또는 Any로 일부 속성을 필터링할 수 있습니다.
7. 여러 속성으로 필터링하려면 이 프로세스를 반복합니다. 여러 속성은 논리 AND로 연결됩니다.
8. 내림차순 또는 오름차순으로 Sort direction을 선택합니다.

환경 또는 배포 날짜

이 기능은 GitLab 13.6에 도입됐습니다.

환경 또는 날짜와 같은 배포 데이터로 Merge Request를 필터링하려면, 다음 사항을 입력합니다(또는 드롭다운 목록에서 선택합니다).

• Environment(환경)
• Deployed-before(배포 전)
• Deployed-after(배포 후)

참고

Fast-forward merge 방법을 사용하는 프로젝트는 결과를 반환하지 않습니다. 이 방법은 merge 커밋을 생성하지 않기 때문입니다.

환경별로 필터링할 때, 드롭다운 목록은 사용자가 선택할 수 있는 모든 환경을 표시합니다.

Deployed-before 또는 Deployed-after로 필터링할 때

• 날짜는 환경(merge 커밋으로 트리거된)에 배포를 성공적으로 완료한 시점을 나타냅니다.
• 배포 날짜를 수동으로 입력해야 합니다.
• 배포 날짜는 YYYY-MM-DD 형식을 사용하고, 날짜와 시간을 모두 지정하려면 양옆에 큰따옴표(")를 표시해야 합니다("YYYY-MM-DD HH:MM").

Merge Request에 변경 사항 추가하기

Merge Request에 변경 사항을 추가하는 권한이 있으면, 변경 사항의 복잡성과 개발 환경에 액세스 권한이 필요한지 여부에 따라 기존 Merge Request에 변경 사항을 여러 방식으로 추가할 수 있습니다.

• . 키보드 단축키로 브라우저에서 Web IDE의 변경 사항을 편집합니다. 여러 파일을 편집하거나, Git 명령이 불편하면 이 브라우저 기반 방법을 사용합니다. Web IDE에서는 테스트를 실행할 수 없습니다.
• 파일을 편집하고 테스트를 실행하는, 모든 기능이 있는 환경이 필요하면 Gitpod에서 변경 사항을 편집합니다. Gitpod는 실행 중인 GitLab Development Kit(GDK) 실행을 지원합니다. Gitpod를 사용하려면, 사용자 계정에서 Gitpod를 활성화해야 합니다.
• Git과 명령줄에 익숙하면 명령줄에서 변경 사항을 푸시합니다.

Merge Request에 사용자 할당하기

사용자에게 Merge Request를 할당하려면, Merge Request의 텍스트 영역에서 /assign @user 퀵 액션을 사용하거나, 또는

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
2. Code > Merge requests를 클릭하고, Merge Request를 찾습니다.
3. 오른쪽 사이드바에서, 오른쪽 사이드바를 펼치고 Assignees 섹션 위치를 찾습니다.
4. Edit을 클릭합니다.
5. 할당하려는 사용자를 검색하고, 사용자를 선택합니다.

Merge Request는 사용자의 담당 Merge Request 목록에 추가됩니다.

여러 사용자 할당하기

(Premium)

이 기능은 GitLab 13.9에서 GitLab Premium 기능으로 이동했습니다.

GitLab에서는 여러 사람이 Merge Request를 담당하면, Merge Request에 여러 담당자를 등록할 수 있습니다.

Merge Request에 여러 담당자를 등록하려면, 텍스트 영역에서 /assign @user 퀵 액션을 사용하거나, 또는

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
2. Code > Merge requests를 클릭하고, Merge Request를 찾습니다.
3. 오른쪽 사이드바에서, 오른쪽 사이드바를 펼치고 Assignees 섹션 위치를 찾습니다.
4. Edit을 클릭하고, 드롭다운 목록에서 Merge Request를 할당하려는 모든 사용자를 선택합니다.

담당자를 제거하려면, 같은 드롭다운 목록에서 사용자를 선택 취소합니다.

Merge Request 닫기

Merge Request에서 작업을 영구적으로 중단하기로 했다면, GitLab은 Merge Request를 삭제하는 대신 이를 닫는 걸 권장합니다. Merge Request 작성자와 담당자, 프로젝트에서 Developer와 Maintainer, Owner 권한이 있는 사용자는 프로젝트의 Merge Request를 닫을 수 있습니다.

1. 닫으려는 Merge Request에 들어갑니다.
2. 페이지 하단의 코멘트 상자로 스크롤 합니다.
3. 코멘트 상자 다음에 있는 Close merge request를 클릭합니다.

GitLab에서 Merge Request를 닫아도 Merge Request, 코멘트, 모든 관련 파이프라인 기록은 보존됩니다.

Merge Request 삭제하기

GitLab은 Merge Request를 삭제하는 대신 닫는 걸 권장합니다.

주의

Merge Request 삭제는 취소할 수 없습니다.

Merge Request를 삭제하려면

1. 프로젝트 Owner 권한이 있는 사용자로 GitLab에 로그인합니다. 이 권한이 있는 사용자만 프로젝트의 Merge Request를 삭제할 수 있습니다.
2. 삭제하려는 Merge Request에 들어가서 Edit을 클릭합니다.
3. 페이지 하단으로 스크롤 하고, Delete merge request를 클릭합니다.

merge 할 때 소스 브랜치 삭제하기

Merge Request의 소스 브랜치를 삭제할 수 있습니다.

• Merge Request를 생성할 때, Delete source branch when merge request accepted를 클릭합니다.
• Merge Request를 merge 할 때, Maintainer 권한이 있다면 Delete source branch를 클릭합니다.

관리자는 프로젝트 설정에서 이 옵션을 기본값으로 설정할 수 있습니다.

타깃 브랜치를 merge 할 때 Merge Request 업데이트 하기

(자체 관리형)

• 이 기능은 GitLab 13.9에 도입됐습니다.
  
• 이 기능은 GitLab 13.9 자체 관리형에서 비활성화됐습니다.
  
• 이 기능은 GitLab 13.10 자체 관리형에서 활성화됐습니다.
  

Merge Request는 종종 서로 연결되며, 하나의 Merge Request는 다른 Merge Request에 추가된 코드 또는 변경된 코드에 따라 달라집니다. 개별 Merge Request를 작게 유지하도록, GitLab에서는 타깃 브랜치를 main 브랜치에 merge 할 때 열려 있는 Merge Request를 최대 4개까지 업데이트 할 수 있습니다. 예를 들어,

• Merge request 1: feature-alpha를 main에 merge 합니다.
• Merge request 2: feature-beta를 feature-alpha에 merge 합니다.

만약 이러한 Merge Request가 동시에 열려 있고 Merge request 1(feature-alpha)이 main에 merge 되면, GitLab은 feature-alpha에서 main으로 Merge request 2 대상을 업데이트 합니다.

서로 연결된 콘텐츠 업데이트가 있는 Merge Request는 다음 방법 중 한 가지 방법으로 보통 처리됩니다.

• Merge request 1은 main에 먼저 merge 됩니다. 그다음, Merge request 2는 main에 다시 타깃 됩니다.
• Merge request 2는 feature-alpha에 merge 됩니다. 업데이트된 Merge request 1은 이제 feature-alpha와 feature-beta 내용을 포함합니다. 이는 main에 merge 됩니다.

이 기능은 Merge Request가 merge 될 때만 동작합니다. merge 한 다음, Remove source branch를 클릭하면 열려 있는 Merge Request를 다시 타깃 하지 않습니다. 이러한 개선 사항은 후속 조치로 제안됩니다.

사이드바 작업 이동하기

• 이 기능은 moved_mr_sidebar라는 플래그와 함께 GitLab 14.10에 도입됐으며, 기본으로 활성화됐습니다.
  
• 이 기능은 GitLab 16.0에서 이슈, 인시던트, 에픽에 작업을 이동하도록 변경됐습니다.

이 피처 플래그가 활성화되면, 오른쪽 상단 코너에 있는 Merge request actions는 다음 작업을 포함합니다.

• 알림 토글
• Merge Request를 'ready' 또는 'draft'로 표시하기
• Merge Request 닫기
• 토론 잠그기
• 레퍼런스 복사하기

GitLab 16.0 이상에서는 비슷한 작업 메뉴를 이슈, 인시던트, 에픽에서 이용할 수 있습니다. 이 피처 플래그가 비활성화되면 이러한 작업은 오른쪽 사이드바에 표시됩니다.

Merge Request 워크플로

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

1. 새로운 브랜치를 확인하고, Merge Request로 변경 사항을 제출합니다.
2. 팀에서 피드백을 수집합니다.
3. Code Quality 보고서로 코드를 최적화하는 작업을 수행합니다.
4. GitLab CI/CD에서 단위 테스트 보고서로 변경 사항을 확인합니다.
5. 라이선스 승인 정책을 사용해 라이선스가 프로젝트와 호환되지 않는 의존성을 사용하지 않도록 합니다.
6. 관리자에게 승인을 요청합니다.
7. 관리자는
   a. 최종 리뷰로 커밋을 푸시합니다.
   b. Merge Request를 승인합니다.
   c. auto-merge로 설정합니다(공식적으로 파이프라인이 성공하면 merge 함)
   
8. 변경 사항은 GitLab CI/CD의 수동 Job으로 프로덕션에 배포됩니다.
9. 구현 결과물이 고객에게 성공적으로 전달됩니다.

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

1. 새로운 브랜치를 확인하고, Merge Request를 통해 새로운 페이지를 제출합니다.
2. 리뷰어에게서 피드백을 수집합니다.
3. Review App으로 변경 사항을 미리 봅니다.
4. 웹 디자이너에게 구현을 요청합니다.
5. 관리자에게 승인을 요청합니다.
6. 승인되면, Merge Request는 squash 되고 merge 되며, GitLab Page로 스테이징에 배포됩니다.
7. 프로덕션 팀은 merge 커밋을 프로덕션에 체리 픽(cherry-pick)합니다.

Merge Request에서 활동 필터링하기

• 이 기능은 mr_activity_filters라는 플래그와 함께 GitLab 15.11에 도입됐으며, 기본으로 비활성화됐습니다.
  
• 이 기능은 GitLab 16.0 GitLab.com에서 활성화됐습니다.
  
• 이 기능은 GitLab 16.3 자체 관리형에서 기본으로 활성화됐습니다.
  
• 이 기능은 GitLab 16.5에서 일반적으로 이용할 수 있습니다. 피처 플래그 mr_activity_filters는 제거됐습니다.
  

Merge Request 이력을 알려면, 활동 피드를 필터링해 사용자와 관련 있는 항목만 보여주도록 합니다.

1. 왼쪽 사이드바에서 Search or go to를 클릭하고, 프로젝트를 찾습니다.
2. Code > Merge requests를 클릭합니다.
3. Merge Request를 선택합니다.
4. Activity로 스크롤 합니다.
5. 페이지 오른쪽에서 Activity filter를 클릭해 필터 옵션을 표시합니다. 이전에 필터 옵션을 선택했다면, 이 필드는 Activity + 5 more와 같이 선택 항목의 요약을 보여줍니다.
6. 사용자가 보려는 활동 유형을 선택합니다. 옵션은 다음 사항을 포함합니다.
   • Assignees & Reviewers
   • Approvals
   • Comments
   • Commits & branches
   • Edits
   • Labels
   • Lock status
   • Mentions
   • Merge request status
   • Tracking
7. 선택사항. 정렬 순서를 바꾸려면 Sort를 클릭합니다.

선택 항목은 모든 Merge Request에 유지됩니다. 오른쪽의 정렬 버튼을 클릭해 정렬 순서를 변경할 수 있습니다.

스레드 해결하기

코멘트를 개별로 해결하는 기능은 GitLab 13.6에서 제거됐습니다.

Merge Request에서 대화를 끝내고 싶을 때, 스레드를 해결할 수 있습니다.

페이지 상단에 해결되지 않은 스레드 수가 업데이트됩니다.

Merge Request에서 해결되지 않은 모든 스레드를 이슈로 이동하기

Merge Request에 해결되지 않은 스레드가 여럿 있으면, 이슈를 만들어 이를 개별로 해결할 수 있습니다. Merge Request 페이지 상단에 있는 스레드 컨트롤에서 생략 아이콘 버튼을 클릭한 다음, Resolve all with new issue를 선택합니다.

모든 스레드가 '해결된 상태'로 표시되고, 링크가 Merge Request에서 새롭게 생성된 이슈로 추가됩니다.

Merge Request에서 해결되지 않은 하나의 스레드를 이슈로 이동하기

Merge Request에서 해결되지 않은 스레드가 하나 있으면, 이슈를 만들어 이를 따로 해결할 수 있습니다. Merge Request에서 스레드의 마지막 댓글 아래 Resolve thread 옆에 Create issue to resolve thread를 클릭합니다.

이 스레드는 '해결된 상태'로 표시되고, 링크는 Merge Request에서 새롭게 만든 이슈로 추가됩니다.

모든 스레드가 해결되지 않으면 merge 막기

모든 스레드가 해결될 때까지 Merge Request가 merge 되는 걸 막을 수 있습니다. 이 설정이 활성화되면, 적어도 하나의 스레드가 해결되지 않을 때 Merge Request에서 Unresolved threads 카운터가 오렌지색으로 표시됩니다.

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

스레드가 오래되면 Merge Request에서 이를 자동 해결하기

줄이 새로운 푸시로 수정될 때, 스레드를 자동으로 해결하도록 Merge Request를 설정할 수 있습니다.

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 섹션이 오래되면 스레드가 이제 해결됩니다. 변경되지 않은 줄의 스레드와 최상위 수준에서 해결할 수 있는 스레드는 해결되지 않습니다.

알림과 to-do를 이동하기

(자체 관리형)

• 이 기능은 notifications_todos_buttons라는 플래그와 함께 GitLab 16.5에 도입됐으며, 기본으로 비활성화됐습니다.
  
• 이슈, 인시던트, 에픽도 업데이트됐습니다.

참고

자체 관리형 GitLab에서는 기본적으로 이 기능을 이용할 수 없습니다. 이 기능을 이용하려면, 관리자가 notifications_todos_buttons라는 피처 플래그를 활성화하면 됩니다. GitLab.com에서는 이 기능을 이용할 수 없습니다.

이 피처 플래그를 활성화할 때, 알림과 to-do 항목 버튼은 페이지 오른쪽 상단 코너로 이동됩니다.

• Merge Request에서 이러한 버튼은 탭의 가장 오른쪽에 있습니다.
• 이슈, 인시던트, 에픽에서 이러한 버튼은 오른쪽 사이드바 상단에 있습니다.

관련 주제

• Merge Request 생성하기
• Merge Request 리뷰하기
• Merge Request 승인
• 테스트와 보고서
• GitLab 키보드 단축키
• 코멘트와 스레드
• 코드 변경 제안하기
• CI/CD 파이프라인
• Merge Request 푸시 옵션

트러블슈팅

Rails 콘솔에서 Merge Request를 rebase 하기

(자체 관리형)

/rebase 퀵 액션 외에도, Rails 콘솔에 액세스 권한이 있는 사용자는 Rails 콘솔에서 Merge Request를 rebase 할 수 있습니다. <username>, <namespace/project>, <iid>를 적절한 값으로 교체합니다.

주의

데이터를 직접 변경하는 명령은 제대로 또는 올바른 조건에서 실행되지 않으면 피해를 줄 수 있습니다. 만일에 대비해 복원할 준비가 된 인스턴스 백업이 있는 테스트 환경에서 이를 실행하도록 권장합니다.

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)

부정확한 Merge Request 상태 수정하기

(자체 관리형)

변경 사항을 merge 한 뒤 Merge Request가 열려 있는 상태로 남아 있으면, Rails 콘솔에 액세스 권한이 있는 사용자는 Merge Request 상태를 수정할 수 있습니다. <username>, <namespace/pjoject>, <iid>를 적절한 값으로 교체합니다.

주의

데이터를 직접 변경하는 명령은 제대로 또는 올바른 조건에서 실행되지 않으면 피해를 줄 수 있습니다. 만일에 대비해 복원할 준비가 된 인스턴스 백업이 있는 테스트 환경에서 이를 실행하도록 권장합니다.

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)

merge 되지 않은 변경 사항이 있는 Merge Request에 이 명령을 실행하면 Merge Request에 부정확한 메시지가 표시됩니다: merged into <branch-name>

Rails 콘솔에서 Merge Request 닫기

(자체 관리형)

UI 또는 API를 통해 Merge Request를 닫을 수 없으면, Rails 콘솔 세션에서 이를 닫으려고 시도할 수 있습니다.

주의

데이터를 변경하는 명령은 제대로 또는 올바른 조건에서 실행되지 않으면 피해를 줄 수 있습니다. 항상 테스트 환경에서 먼저 명령을 실행하고, 백업 인스턴스가 복원할 준비가 되도록 합니다.

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::CloseService.new(project: p, current_user: u).execute(m)

Rails 콘솔에서 Merge Request 삭제하기

(자체 관리형)

UI 또는 API를 통해 Merge Request를 삭제할 수 없으면, Rails 콘솔 세션에서 이를 삭제하려고 시도할 수 있습니다.

주의

데이터를 직접 변경하는 명령은 제대로 또는 올바른 조건에서 실행되지 않으면 피해를 줄 수 있습니다. 만일에 대비해 복원할 준비가 된 인스턴스 백업이 있는 테스트 환경에서 이를 실행하도록 권장합니다.

u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
Issuable::DestroyService.new(container: m.project, current_user: u).execute(m)

Merge Request pre-receive 훅(hook) 실패

Merge Request가 시간 초과하면 Puma 워커 시간 초과 문제를 나타내는 메시지를 볼 수 있습니다.

• GitLab UI에서

Something went wrong during merge pre-receive hook.
500 Internal Server Error. Try again.

• gitlab-rails/api_json.log 로그 파일에서

Rack::Timeout::RequestTimeoutException
Request ran for longer than 60000ms

사용자의 Merge Request가 다음 사항에 해당하면 오류가 생길 수 있습니다.

• diff를 많이 포함할 때
• 타깃 브랜치 뒤에 커밋이 많을 때

자체 관리형 설치 사용자는 관리자에게 서버 로그를 리뷰하도록 요청해 오류 원인을 파악할 수 있습니다. GitLab SaaS 사용자는 도움을 받으려면 지원팀에 연락해야 합니다.

GitLab 원문 보기