Merge Request

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • 변경된 사이드바 작업 메뉴를 GitLab 16.0에서 이슈, 인시던트 및 엡릭스 작업으로 이동하기 위해서 변경했습니다.
  • GitLab 16.9에서 일반적으로 사용 가능합니다. moved_mr_sidebar 피처 플래그가 제거되었습니다.

Merge Request(MR)은 소스 브랜치에서 대상 브랜치로 변경사항을 포함시키기 위한 제안입니다.

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

  • 요청 설명.
  • 코드 변경 및 인라인 코드 리뷰.
  • CI/CD 파이프라인 정보.
  • 토론 스레드를 위한 코멘트 섹션.
  • 커밋 디렉터리.

Merge Request 생성

Merge Request을 생성하는 다양한 방법을 알아보세요.

Merge Request 템플릿 사용

Merge Request을 생성할 때, GitLab은 Merge Request에 데이터를 추가하기 위해 설명 템플릿의 존재 여부를 확인합니다. GitLab은 다음 위치를 확인하고, 찾은 첫 번째 템플릿을 Merge Request에 적용합니다:

이름 프로젝트 UI
설정 		그룹
default.md 		인스턴스
default.md 		프로젝트
default.md 		템플릿 없음
표준 커밋 메시지 1 2 3 4 5
Closes #1234와 같은 이슈 종료 패턴을 포함한 커밋 메시지 1 2 3 4 5 *
이슈 ID로 접두어가 붙은 브랜치 이름, 예: 1234-example 1 * 2 * 3 * 4 * 5 *
note
별표(*)가 표시된 항목은 이슈 종료 패턴을 추가로 결합합니다.

Merge Request 보기

프로젝트, 그룹 또는 본인의 Merge Request을 볼 수 있습니다.

프로젝트의 경우

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Code > Merge Request을 선택합니다.

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

그룹 내 모든 프로젝트의 경우

그룹 내 모든 프로젝트의 Merge Request을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. Code > Merge Request을 선택합니다.

그룹에 서브그룹이 포함된 경우 이 보기는 서브그룹 프로젝트의 Merge Request도 표시합니다.

본인에게 할당된 경우

본인에게 할당된 모든 Merge Request을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택합니다.
  2. 드롭다운 디렉터리에서 내게 할당된 Merge Request을 선택합니다.

또는:

또는:

  1. 왼쪽 사이드바에서 Code > Merge Request ()을 선택합니다.
  2. 드롭다운 디렉터리에서 할당됨을 선택합니다.

Merge Request 디렉터리 필터링

  • source-branch로의 필터링은 GitLab 16.6에서 도입되었습니다.
  • merged-by로의 필터링은 GitLab 16.9에서 도입되었습니다. 피처 플래그 mr_merge_user_filter가 활성화될 때에만 사용할 수 있습니다.
  • merged-by로의 필터링은 GitLab 17.0에서 일반적으로 사용 가능합니다. 피처 플래그 mr_merge_user_filter가 제거되었습니다.

Merge Request 디렉터리을 필터링하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Code > Merge Request을 선택합니다.
  3. Merge Request 디렉터리 상단에서 검색 또는 결과 필터링을 선택합니다.
  4. 드롭다운 디렉터리에서 필터링하려는 속성을 선택합니다. 몇 가지 예는 다음과 같습니다:
    • 환경 또는 배포 날짜별.
    • ID: #30 필터를 입력하여 Merge Request 30만 반환합니다.
    • 사용자 필터: 사용자 디렉터리을 표시하려면 이러한 필터 중 하나를 입력(또는 드롭다운 디렉터리에서 선택)합니다:
      • Approved-By: 사용자에 의해 이미 승인된 Merge Request을 나타냅니다. Premium 및 Ultimate 전용.
      • Approver: 이 사용자가 승인할 수 있는 Merge Request을 나타냅니다. (자세한 내용은 코드 소유자를 참조하세요). Premium 및 Ultimate 전용.
      • Merged-By: 이 사용자가 Merge한 Merge Request을 나타냅니다.
      • Reviewer: 이 사용자가 검토한 Merge Request을 나타냅니다.
  5. 필터링 속성에 사용할 오퍼레이터를 선택하거나 입력합니다. 다음 오퍼레이터를 사용할 수 있습니다:
    • =: 일치
    • !=: 불일치
  6. 필터링할 속성을 기준으로 텍스트를 입력합니다. 몇 가지 속성은 없음 또는 아무거나로 필터링할 수 있습니다.
  7. 여러 속성으로 필터링하려면 이 프로세스를 반복합니다. 여러 속성은 논리 AND로 연결됩니다.
  8. 정렬 방향을 선택하여 은 내림차순, 은 오름차순으로 정렬할 수 있습니다.

환경 또는 배포 날짜별

환경 또는 날짜와 같은 배포 데이터로 Merge Request을 필터링하려면 다음을 입력(또는 드롭다운 디렉터리에서 선택)할 수 있습니다:

  • 환경
  • 이전에 배포된 날짜
  • 이후에 배포된 날짜
note
빠른 전진 Merge 방법을 사용하는 프로젝트는 결과를 반환하지 않습니다. 이 방법은 Merge 커밋을 생성하지 않습니다.

환경으로 필터링하려면 드롭다운 디렉터리에서 선택할 수 있는 모든 환경이 나타납니다.

이전에 배포된 날짜 또는 이후에 배포된 날짜로 필터링하면:

  • 날짜는 배포된 환경(Merge 커밋으로 인한 트리거)에서 성공적으로 완료된 배포 날짜를 의미합니다.
  • 배포 날짜는 매뉴얼으로 입력해야 합니다.
  • 배포 날짜는 YYYY-MM-DD 형식을 사용하고, 날짜 및 시간을 지정하려면 큰따옴표(")로 묶어야 합니다("YYYY-MM-DD HH:MM").

Merge Request에 변경사항 추가

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

Merge Request에 사용자 할당

Merge Request을 사용자에게 할당하려면 Merge Request 내의 텍스트 영역에서 /assign @user 빠른 작업을 사용하거나 다음을 사용하세요.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 코드 > Merge Request을 선택하고 Merge Request을 찾습니다.
  3. 오른쪽 사이드바에서 오른쪽 사이드바를 확장하고 담당자 섹션을 찾습니다.
  4. 편집을 선택합니다.
  5. 할당하려는 사용자를 검색하고 사용자를 선택합니다.

Merge Request은 사용자의 할당된 Merge Request 디렉터리에 추가됩니다.

여러 사용자 할당

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

GitLab은 여러 명의 담당자를 Merge Request에 할당할 수 있도록 합니다.

Merge Request을 위한 여러 담당자 사이드바

Merge Request에 여러 명의 담당자를 할당하려면 텍스트 영역에서 /assign @user 빠른 작업을 사용하거나 다음을 사용하세요.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 코드 > Merge Request을 선택하고 Merge Request을 찾습니다.
  3. 오른쪽 사이드바에서 오른쪽 사이드바를 확장하고 담당자 섹션을 찾습니다.
  4. 편집을 선택하고, 드롭다운 디렉터리에서 할당하려는 모든 사용자를 선택합니다.

담당자를 제거하려면 동일한 드롭다운 디렉터리에서 사용자를 지웁니다.

Merge Request 닫기

만약 Merge Request에 대한 작업을 영구적으로 중지하기로 결정한다면, GitLab은 Merge Request을 삭제하는 대신 닫는 것을 권장합니다.

전제 조건:

  • Merge Request의 작성자 또는 담당자이어야 합니다.
  • 프로젝트에서 Developer, Maintainer, 또는 Owner 역할을 가지고 있어야 합니다.

프로젝트에서 Merge Request을 닫으려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 코드 > Merge Request을 선택하고 Merge Request을 찾습니다.
  3. 페이지 하단의 코멘트 상자로 스크롤합니다.
  4. 코멘트 상자 아래에서 Merge Request 닫기을(를) 선택합니다.

GitLab은 Merge Request을 닫지만, Merge Request과 관련된 기록 및 파이프라인은 보존합니다.

Merge 시 소스 브랜치 삭제

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

  • Merge Request을 생성할 때, Merge Request이 승인될 때 소스 브랜치 삭제를 선택하는 경우
  • Merge Request을 Merge할 때, Maintainer 역할을 가지고 있는 경우, 소스 브랜치 삭제를 선택하는 경우

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

대상 브랜치가 Merge될 때 Merge Request 업데이트

Tier: Free, Premium, Ultimate Offering: Self-Managed
  • GitLab 16.9에서 연결된 Merge Request이 변경되어 새 대상 브랜치에 자동으로 다시베이스되도록 변경되었습니다.
  • GitLab 16.10에서 연결된 Merge Request은 더 이상 자동으로 새 대상 브랜치에 재베이스하지 않으며, :rebase_when_retargetting_mrs라는 플래그가 있습니다. 기본적으로 비활성화됨.
Self-Managed GitLab에서는 기본적으로이 기능을 사용할 수 없습니다. 관리자는 :rebase_when_retargetting_mrs라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는이 기능을 사용할 수 없습니다.

Merge Request은 종종 서로 연결되어 있으며, 한 Merge Request이 다른 Merge Request에서 추가 또는 변경된 코드에 종속되어 있습니다. 개별 Merge Request의 크기를 유지하기 위한 지원으로, GitLab은 main에 대상 브랜치가 Merge될 때 최대 네 개의 열린 Merge Request을 업데이트할 수 있습니다. 예를 들어:

  • 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은 Merge Request 2의 대상을 feature-alpha에서 main으로 업데이트합니다.

상호 연결된 콘텐츠 업데이트가 필요한 Merge Request은 일반적으로 다음 중 하나의 방법으로 처리됩니다.

  • Merge Request 1이 먼저 main으로 Merge됩니다. 그런 다음 Merge Request 2가 main으로 재지정됩니다.
  • Merge Request 2가 feature-alpha로 Merge됩니다. 콘텐츠가 업데이트된 Merge Request 1이 이제 main으로 Merge됩니다.

이 기능은 Merge Request이 Merge될 때만 작동합니다. Merge 후 소스 브랜치 제거를 선택하더라도 열린 Merge Request을 재지정하지 않습니다. 이 향상은 추후 제안으로 제안되었습니다.

Merge Request 작업 흐름

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

  1. 새 브랜치를 확인하고 Merge Request을 통해 변경 사항을 제출합니다.
  2. 팀에서 피드백을 수집합니다.
  3. 코드 품질 보고서를 사용하여 코드 최적화 구현을 수행합니다.
  4. GitLab CI/CD에서 단위 테스트 보고서로 변경 사항을 검증합니다.
  5. 프로젝트와 호환되지 않는 라이선스의 의존성을 피하기 위해 라이선스 승인 정책을 사용합니다.
  6. 당신의 매니저로부터 승인을 요청합니다.
  7. 당신의 매니저:
    1. 최종 검토를 위해 커밋을 푸시합니다.
    2. Merge Request을 승인합니다.
    3. 파이프라인 성공 시 Merge으로 설정합니다 (이전에는 파이프라인 성공 시 Merge으로 알려짐).
  8. 당신의 변경 내용이 매뉴얼 작업으로 GitLab CI/CD에 배포됩니다.
  9. 당신의 구현이 고객에게 성공적으로 제공되었습니다.

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

  1. 새로운 브랜치를 확인하고 Merge Request을 통해 새 페이지를 제출합니다.
  2. 리뷰어로부터 피드백을 수집합니다.
  3. 리뷰 앱로 변경 사항을 미리 볼 수 있습니다.
  4. 웹 디자이너에게 구현을 요청합니다.
  5. 당신의 매니저로부터 승인을 요청합니다.
  6. 승인되면, 당신의 Merge Request이 통합 및 Merge되며 GitLab 페이지로 배포됩니다.
  7. 프로덕션 팀은 Merge 커밋을 프로덕션으로 체리 픽합니다.

Merge Request에서 활동 필터링

  • GitLab 15.11에서 mr_activity_filters라는 피처 플래그로 도입됨. 기본적으로 비활성화됨.
  • GitLab 16.0에서 GitLab.com에서 활성화됨.
  • GitLab 16.3에서 Self-Managed에서 기본적으로 활성화됨.
  • GitLab 16.5에서 일반 사용 가능. 피처 플래그 mr_activity_filters가 제거됨.
  • 연결된 Bot 코멘트에 대한 필터링은 GitLab 16.9에서 도입됨.

Merge Request의 이력을 이해하기 위해, 필터를 사용하여 관련 항목만 표시하는 활동 피드를 필터링합니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 코드 > Merge Request을 선택합니다.
  3. Merge Request을 선택합니다.
  4. 활동으로 스크롤합니다.
  5. 페이지 오른쪽에 활동 필터를 선택하여 필터 옵션을 표시합니다. 이전에 필터 옵션을 선택한 경우, 이 필드에는 활동 + 5개 더보기와 같은 선택 사항의 요약이 표시됩니다.

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

    • 담당자 및 리뷰어
    • 승인
    • 코멘트 (봇으로부터)
    • 코멘트 (사용자로부터)
    • 커밋 & 브랜치
    • 편집
    • 라벨
    • 잠금 상태
    • 언급
    • Merge Request 상태
    • 추적
  7. 선택 사항. 정렬을 반대로하려면 정렬()을 선택합니다.

선택 사항은 모든 Merge Request에서 지속됩니다. 또한 오른쪽의 정렬 버튼을 클릭하여 정렬 순서를 변경할 수 있습니다.

스레드 해결

회의가 종료되길 원할 때 스레드를 해결합니다.

미해결된 스레드 수는 Merge Request의 오른쪽 상단에 표시됩니다. 이렇게 보입니다: 7개의 미해결된 스레드.

Merge Request의 모든 미해결된 스레드를 이슈로 이동

Merge Request에 여러 개의 미해결된 스레드가 있다면, 따로 이들을 해결하기 위해 이슈를 생성할 수 있습니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. Code > Merge Request를 선택하고 Merge Request을 찾습니다.
  3. Merge Request에서 오른쪽 상단에 있는 미해결된 스레드 드롭다운 디렉터리을 찾아 스레드 옵션 ()을 선택합니다.
  4. 새 이슈로 모두 해결을 선택합니다.
  5. 새 이슈의 필드를 작성하고 이슈 만들기를 선택합니다.

모든 스레드는 해결되며, Merge Request에서 새로 생성된 이슈로 링크가 추가됩니다.

Merge Request의 하나의 미해결된 스레드를 이슈로 이동

Merge Request에 특정 미해결된 스레드가 하나 있다면, 따로 이를 해결하기 위해 이슈를 생성할 수 있습니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. Code > Merge Request를 선택하고 Merge Request을 찾습니다.
  3. 원하는 스레드가 있는 Merge Request을 찾습니다.
  4. 스레드의 마지막 답글 아래에서 스레드 해결 옆에 있는 스레드를 해결하기 위해 이슈 생성을 선택합니다 ().
  5. 새 이슈의 필드를 작성하고 이슈 만들기를 선택합니다.

스레드는 해결로 표시되며, Merge Request에서 새로 생성된 이슈로 링크가 추가됩니다.

모든 스레드가 해결되지 않으면 Merge을 허용하지 않으려면

모든 스레드가 해결될 때까지 Merge Request이 Merge되는 것을 막을 수 있습니다. 이 설정이 활성화되면, Merge Request의 미해결된 스레드 카운터는 최소한 하나의 스레드가 해결되지 않았을 때 주황색으로 표시됩니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 설정 > Merge Request을 선택합니다.
  3. Merge 체크 섹션에서 모든 스레드가 해결되어야 함 확인란을 선택합니다.
  4. 변경 사항 저장을 선택합니다.

스레드가 오래되었을 때 Merge Request에서 자동으로 해결

새로운 푸시로 줄이 수정되면 Merge Request에서 스레드를 자동으로 해결하도록 Merge Request을 설정할 수 있습니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 설정 > Merge Request을 선택합니다.
  3. Merge 옵션 섹션에서 줄이 오래되었을 때 Merge Request 차이 스레드 자동으로 해결을 선택합니다.
  4. 변경 사항 저장을 선택합니다.

푸시로 수정 사항이 스레드를 오래된 것으로 만들면 이제 스레드는 해결됩니다. 변경되지 않는 줄의 스레드 및 상위 수준의 해결 가능한 스레드는 해결되지 않습니다.

이동 통지 및 할 일

DETAILs: Tier: Free, Premium, Ultimate Offering: Self-Managed

Self-Managed GitLab에선 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 notifications_todos_buttons라는 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

이 피처 플래그가 활성화되면, 통지 및 할 일 항목 버튼이 페이지의 오른쪽 상단으로 이동됩니다.

  • Merge Request에선 이들 버튼이 탭의 가장 오른쪽에 있습니다.
  • 이슈, 사건 및 에픽에선 이들 버튼이 오른쪽 사이드바 상단에 위치합니다.

관련 주제