히스토리

• 사이드바 작업 메뉴가 GitLab 16.0에서 이슈, 인시던트 및 에픽에 대한 작업도 이동하도록 변경되었습니다.
• GitLab 16.9에서 일반 사용 가능. 기능 플래그 moved_mr_sidebar가 제거되었습니다.

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

머지 리퀘스트는 주제 전문가가 제안된 변경 사항을 검토하고 조직의 보안 요구 사항이 충족되는지 확인하는 데 도움을 줍니다. 개발 프로세스 초기에 머지 리퀘스트를 생성하면 팀이 버그 및 코드 품질 문제를 발견할 시간이 있습니다.

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

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

머지 리퀘스트 생성#

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

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

머지 리퀘스트를 생성할 때 GitLab은 머지 리퀘스트에 데이터를 추가할 설명 템플릿이 있는지 확인합니다. GitLab은 1에서 5까지 순서대로 이러한 위치를 확인하고 머지 리퀘스트에 찾은 첫 번째 템플릿을 적용합니다:

머지 리퀘스트 보기#

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

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

히스토리

• source branch로 필터링이 GitLab 16.6에서 도입되었습니다.
• 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. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 코드 > 머지 리퀘스트를 선택합니다.
3. 머지 리퀘스트 목록 위에서 결과 검색 또는 필터링을 선택합니다.
4. 드롭다운 목록에서 필터링할 속성을 선택합니다. 몇 가지 예:
   • 환경 또는 배포 날짜별.
   • ID: 필터 #30을 입력하면 머지 리퀘스트 30만 반환됩니다.
   • 사용자 필터: 다음 필터 중 하나를 입력(또는 드롭다운 목록에서 선택)하여 사용자 목록을 표시합니다:
     • 승인함, 사용자가 이미 승인한 머지 리퀘스트용. Premium 및 Ultimate만 해당.
     • 승인자, 이 사용자가 승인할 자격이 있는 머지 리퀘스트용. (자세한 내용은 코드 소유자에 대해 읽어보십시오). Premium 및 Ultimate만 해당.
     • 머지한 사람, 이 사용자가 머지한 머지 리퀘스트용.
     • 검토자, 이 사용자가 검토한 머지 리퀘스트용.
5. 속성을 필터링하는 데 사용할 연산자를 선택하거나 입력합니다. 사용 가능한 연산자:
   • =: 같음
   • !=: 같지 않음
6. 속성을 필터링할 텍스트를 입력합니다. 일부 속성은 없음 또는 임의로 필터링할 수 있습니다.
7. 논리적 AND로 연결된 추가 속성으로 필터링하려면 이 프로세스를 반복합니다.
8. 정렬 방향을 선택합니다. 내림차순의 경우 [sort-lowest], 오름차순의 경우 [sort-highest].

환경 또는 배포 날짜별#

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

• 환경
• 이전 배포
• 이후 배포

환경별로 필터링할 때 드롭다운 목록에 선택할 수 있는 모든 환경이 표시됩니다.

이전 배포 또는 이후 배포로 필터링할 때:

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

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

머지 리퀘스트에 변경 사항을 추가할 권한이 있는 경우 기존 머지 리퀘스트에 여러 가지 방법으로 변경 사항을 추가할 수 있습니다. 이러한 방법은 변경의 복잡성과 개발 환경에 대한 액세스가 필요한지 여부에 따라 달라집니다:

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

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

머지 리퀘스트에 사용자를 할당하려면 머지 리퀘스트의 텍스트 영역에서 /assign @user 빠른 작업을 사용하거나:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

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

3. 오른쪽 사이드바에서 오른쪽 사이드바를 확장하고 담당자 섹션을 찾습니다.

4. 편집을 선택합니다.

5. 할당할 사용자를 검색하고 사용자를 선택합니다. GitLab Free는 머지 리퀘스트당 담당자 1명을 허용하지만 GitLab Premium과 GitLab Ultimate는 여러 담당자를 허용합니다:

   

GitLab은 사용자의 할당된 머지 리퀘스트 페이지에 머지 리퀘스트를 추가합니다.

참여자#

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

머지 리퀘스트 머지#

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

기본 머지 권한:

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

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

• 프로젝트에서의 권한. 예를 들어 Developer, Maintainer 또는 Owner.
• 대상 브랜치의 브랜치 보호.

머지 리퀘스트 닫기#

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

사전 요구사항:

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

프로젝트에서 머지 리퀘스트를 닫으려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 코드 > 머지 리퀘스트를 선택하고 머지 리퀘스트를 찾습니다.
3. 페이지 하단의 댓글 상자로 스크롤합니다.
4. 댓글 상자 다음에서 머지 리퀘스트 닫기를 선택합니다.

GitLab은 머지 리퀘스트를 닫지만 머지 리퀘스트, 댓글 및 관련 파이프라인의 기록은 보존합니다.

머지 시 소스 브랜치 삭제#

머지 리퀘스트의 소스 브랜치를 삭제할 수 있습니다:

• 머지 리퀘스트를 생성할 때 머지 리퀘스트 승인 시 소스 브랜치 삭제를 선택합니다.
• 머지 리퀘스트를 머지할 때 Maintainer 권한이 있는 경우 소스 브랜치 삭제를 선택합니다.

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

브랜치 삭제 작업은 자동 머지를 설정하거나 머지 리퀘스트를 머지하는 사용자가 수행합니다. 사용자에게 올바른 권한이 없는 경우(예: 포크 프로젝트에서) 소스 브랜치 삭제가 실패합니다.

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

머지 리퀘스트는 종종 서로 연결되어 있으며, 하나의 머지 리퀘스트가 다른 머지 리퀘스트에서 추가되거나 변경된 코드에 종속됩니다. 개별 머지 리퀘스트를 작게 유지하는 것을 지원하기 위해 GitLab은 대상 브랜치가 main에 머지될 때 최대 4개의 열린 머지 리퀘스트를 업데이트할 수 있습니다. 예를 들어:

• 머지 리퀘스트 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에 머지됩니다.

이 기능은 머지 리퀘스트가 머지될 때만 작동합니다. 머지 후 소스 브랜치 제거를 선택해도 열린 머지 리퀘스트의 대상이 변경되지 않습니다. 이 개선 사항은 후속 조치로 제안되었습니다.

머지 리퀘스트 워크플로#

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

1. 새 브랜치를 체크아웃하고 머지 리퀘스트를 통해 변경 사항을 제출합니다.
2. 팀의 피드백을 수집합니다.
3. 코드 품질 보고서로 코드를 최적화하여 구현합니다.
4. GitLab CI/CD에서 단위 테스트 보고서로 변경 사항을 확인합니다.
5. 라이선스 승인 정책으로 프로젝트와 호환되지 않는 라이선스를 가진 종속성 사용을 방지합니다.
6. 관리자에게 승인을 요청합니다.
7. 관리자:
   1. 최종 검토와 함께 커밋을 푸시합니다.
   2. 머지 리퀘스트를 승인합니다.
   3. 자동 머지(이전의 파이프라인 성공 시 머지)로 설정합니다.
8. GitLab CI/CD의 수동 Job으로 변경 사항이 프로덕션에 배포됩니다.
9. 구현이 고객에게 성공적으로 제공되었습니다.

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

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

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

히스토리

• 기능 플래그 mr_activity_filters가 GitLab 16.0에서 GitLab.com에서 활성화되었습니다.
• GitLab 16.3에서 기본적으로 GitLab Self-Managed에서 활성화되었습니다.
• GitLab 16.5에서 일반 사용 가능. 기능 플래그 mr_activity_filters가 제거되었습니다.
• GitLab 16.9에서 봇 댓글 필터링이 도입되었습니다.

머지 리퀘스트의 역사를 이해하려면 활동 피드를 필터링하여 관련 항목만 표시합니다.

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 코드 > 머지 리퀘스트를 선택합니다.

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

4. 활동으로 스크롤합니다.

5. 페이지 오른쪽에서 활동 필터를 선택하여 필터 옵션을 표시합니다. 이미 필터 옵션을 선택한 경우 이 필드에는 활동 + 5개 더와 같은 선택 요약이 표시됩니다.

6. 보려는 활동 유형을 선택합니다. 옵션은 다음과 같습니다:

   • 담당자 및 검토자
   • 승인
   • 댓글 (봇에서)
   • 댓글 (사용자에서)
   • 커밋 및 브랜치
   • 편집
   • 레이블
   • 잠금 상태
   • 언급
   • 머지 리퀘스트 상태
   • 추적

7. 선택 사항. 정렬 ([sort-lowest])을 선택하여 정렬 순서를 반전합니다.

선택 사항은 모든 머지 리퀘스트에 걸쳐 유지됩니다. 오른쪽의 정렬 버튼을 클릭하여 정렬 순서를 변경할 수도 있습니다.

댓글 스레드 관리#

머지 리퀘스트의 토론에는 단일 댓글과 댓글 스레드가 포함됩니다. 열린(해결되지 않은) 스레드는 머지 리퀘스트의 머지를 차단하지만 단일 댓글은 차단하지 않습니다. 스레드의 토론이 끝나면 스레드를 해결하여 표시를 접습니다. 댓글 스레드가 중요하지만 머지 리퀘스트를 차단해서는 안 되는 경우 토론을 계속하기 위해 이슈로 이동합니다.

모든 스레드 확장#

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

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 코드 > 머지 리퀘스트를 선택하고 머지 리퀘스트를 찾습니다.
3. 머지 리퀘스트에서 오른쪽 상단의 열린 스레드 드롭다운 목록을 찾고 스레드 옵션 (⋮)을 선택합니다.
4. 모든 댓글 표시를 선택합니다.

이슈로 열린 스레드 이동#

열린 스레드를 새 이슈로 이동하고 머지 리퀘스트 차단을 해제하려면:

모든 스레드가 해결될 때까지 머지 방지#

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > 머지 리퀘스트를 선택합니다.
3. 머지 검사 섹션에서 모든 스레드를 해결해야 합니다 체크박스를 선택합니다.
4. 변경사항 저장을 선택합니다.

머지 리퀘스트의 스레드를 오래된 경우 자동으로 해결#

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > 머지 리퀘스트를 선택합니다.
3. 머지 옵션 섹션에서 오래된 경우 머지 리퀘스트 diff 스레드를 자동으로 해결을 선택합니다.
4. 변경사항 저장을 선택합니다.

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

알림 및 할 일 이동#

히스토리

• GitLab 16.5에서 notifications_todos_buttons라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• 이슈, 인시던트 및 에픽도 업데이트되었습니다.

이 기능 플래그를 활성화하면 알림 및 할 일 항목 버튼이 페이지 오른쪽 상단으로 이동됩니다.

• 머지 리퀘스트에서 이러한 버튼은 탭 오른쪽 끝에 표시됩니다.
• 이슈, 인시던트 및 에픽에서 이러한 버튼은 오른쪽 사이드바 상단에 표시됩니다.

관련 항목#

• 리포지터리 보호
• 머지 리퀘스트 검토
• 머지 리퀘스트 인증
• 테스팅 및 보고서
• 댓글 및 스레드
• 코드 변경 제안
• CI/CD 파이프라인
• 머지 리퀘스트를 위한 푸시 옵션
• 머지 리퀘스트 제목 유효성 검사