Merge 방법

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

프로젝트에서 선택한 Merge 방법은 Merge Request에서의 변경 사항이 기존 브랜치에 어떻게 Merge되는지를 결정합니다.

이 페이지의 예제는 커밋 A, C, 및 E가 담긴 main 브랜치와 커밋 B와 D가 담긴 feature 브랜치를 가정합니다.

gitGraph commit id: "A" branch feature commit id: "B" commit id: "D" checkout main commit id: "C" commit id: "E"

프로젝트의 Merge 방법 구성

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > Merge Request을 선택합니다.
  3. 다음 옵션 중 원하는 Merge 방법을 선택합니다:
    • Merge 커밋
    • 반선형 히스토리를 가진 Merge 커밋
    • 빠른-Merge
  4. Merge 시 커밋 통합에서 커밋 처리를 위한 기본 동작을 선택합니다:
    • 허용하지 않음: 통합이 절대로 수행되지 않으며 사용자는 동작을 변경할 수 없습니다.
    • 허용: 통합은 기본적으로 꺼져 있지만 사용자는 동작을 변경할 수 있습니다.
    • 권장: 통합은 기본적으로 켜져 있지만 사용자는 동작을 변경할 수 있습니다.
    • 필수: 통합은 항상 수행되며 사용자는 동작을 변경할 수 없습니다.
  5. 변경 사항 저장을 선택합니다.

Merge 커밋

기본적으로 GitLab은 브랜치가 main에 Merge될 때 Merge 커밋을 생성합니다. 커밋을 통합할 때 별도의 Merge 커밋이 항상 생성되며, 커밋들이 통합할 때 통합되는 경우와 관계 없이 이 전략을 사용하면 main 브랜치에 스쿼시 커밋과 Merge 커밋이 추가될 수 있습니다.

다음 다이어그램은 Merge 커밋 전략을 사용할 때 feature 브랜치가 main에 Merge되는 방법을 보여줍니다. 이들은 git merge --no-ff <feature> 명령어와 GitLab UI에서 Merge 방법으로 Merge 커밋을 선택하는 것과 동등합니다.

Merge 전략:

%%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main'}} }%% gitGraph commit id: "A" branch feature commit id: "B" commit id: "D" checkout main commit id: "C" commit id: "E" merge feature

Merge 커밋 방법을 사용하여 피처 브랜치가 Merge된 후 main 브랜치는 다음과 같이 보입니다:

%%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main'}} }%% gitGraph commit id: "A" commit id: "C" commit id: "E" commit id: "스쿼시 커밋" commit id: "Merge 커밋"

반면 스쿼시 Merge은 feature 브랜치의 모든 커밋의 가상 복사인 스쿼시 커밋을 생성합니다. 원본 커밋들 (B와 D)은 feature 브랜치에서 변경되지 않은 채로 스쿼시 커밋이 main 브랜치에 배치됩니다:

%%{init: { 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main'}} }%% gitGraph commit id:"A" branch feature checkout main commit id:"C" checkout feature commit id:"B" commit id:"D" checkout main commit id:"E" commit id:"스쿼시 커밋" type: HIGHLIGHT

스쿼시 Merge 그래프는 GitLab UI에서 다음과 같은 설정과 동등합니다:

  • Merge 방법: Merge 커밋.
  • Merge할 때 스쿼시 커밋은 다음 중 하나여야 합니다:
    • 필수.
    • 허용 또는 권장하며 Merge Request에서 스쿼시가 선택되어 있어야 합니다.

스쿼시 Merge 그래프는 또한 다음 명령어와 동등합니다: 

git checkout `git merge-base feature main`
git merge --squash <feature>
SOURCE_SHA=`git rev-parse HEAD`
git checkout <main>
git merge --no-ff $SOURCE_SHA

반선형 히스토리를 가진 Merge 커밋

모든 Merge에 대해 Merge 커밋이 생성되지만 Merge이 가능한 경우에만 브랜치가 Merge됩니다. 이를 통해 Merge Request 빌드가 성공하면, Merge 후에 대상 브랜치 빌드도 성공하도록 보장합니다. 이 Merge 방법을 사용하여 생성한 예제 커밋 그래프:

gitGraph commit id: "초기화" branch mr-branch-1 commit commit checkout main merge mr-branch-1 branch mr-branch-2 commit commit checkout main merge mr-branch-2 commit branch 스쿼시-mr commit id: "스쿼시된 커밋들" checkout main merge 스쿼시-mr

반선형 히스토리를 가진 Merge 커밋 메서드를 선택하여 Merge Request 페이지를 방문하면 만약 브랜치가 빠른-Merge될 수 있는 경우만 수락할 수 있습니다. 빠른-Merge이 불가능할 때는 사용자가 리베이스할 수 있는 옵션이 제공됩니다. 반선형 Merge 방법에서 리베이스하기를 참조하세요.

이 방법은 Merge 커밋 방법과 동일한 Git 명령어를 사용합니다. 그러나 소스 브랜치가 대상 브랜치 (예: main)의 오래된 버전에 기반한다면 소스 브랜치를 rebase해야 합니다. 이 Merge 방법을 사용하면 더 깔끔한 히스토리가 생성되지만 모든 브랜치가 어디서 시작되었고 Merge되었는지를 여전히 볼 수 있습니다.

빠른-Merge

때로는 작업 정책이 Merge 커밋 없는 깔끔한 커밋 히스토리를 요구할 수 있습니다. 이런 경우 빠른-Merge이 적절합니다. 빠른-Merge Request은 통합된 Merge 커밋을 생성하지 않는 선에서 merge 요청을 수락할 수 있는 방법을 유지합니다. 이 Merge 방법을 사용하여 생성한 예제 커밋 그래프:

gitGraph commit id: "초기화" commit id: "mr-branch-1 Merge" commit id: "mr-branch-2 Merge" commit id: "main에 커밋" commit id: "스쿼시 Merge"

빠른-Merge(--ff-only 설정이 활성화되면 Merge 커밋이 생성되지 않고 모든 Merge은 빠르게 전진됩니다. Merge은 브랜치가 빠른-Merge될 수 있는 경우에만 허용됩니다. 빠른-Merge이 불가능할 때는 사용자가 리베이스할 수 있는 옵션이 제공됩니다. 반선형 Merge 방법에서 리베이스하기를 참조하세요.

note
빠른-Merge 전략을 사용하는 프로젝트는 Merge Request 디렉터리 필터링을 할 수 없으며, 이는 Merge 커밋이 생성되지 않기 때문에 배포 날짜별로 Merge Request을 필터링할 수 없다는 것입니다. 빠른-Merge이 활성화된 상태에서 배포-MR 관계에 의존하는 기능은 작동하지 않습니다. 이 버그는 이슈 398611에서 추적 중입니다.

빠른-Merge 방법을 선택하여 Merge Request 페이지를 방문하면 만약 브랜치가 빠른-Merge될 수 있는 경우만 수락할 수 있습니다.

빠른-Merge Merge Request

(반)선형 Merge 방법에서의 리베이스

이러한 Merge 방법에서는 소스 브랜치가 타겟 브랜치와 최신 상태일 때만 Merge할 수 있습니다:

  • 반선형 히스토리로 Merge 커밋
  • 빠른-앞으로 Merge

빠른-앞으로 Merge이 불가능하지만 충돌이 없는 리베이스가 가능하면, GitLab은 다음을 제공합니다:

두 가지 조건이 모두 참인 경우에는 빠른-앞으로 Merge 전에 소스 브랜치를 로컬에서 리베이스해야 합니다:

  • 타겟 브랜치가 소스 브랜치보다 앞서 있음.
  • 충돌이 없는 리베이스가 불가능함.

빠른-앞으로 Merge을 로컬에서 리베이스

스쿼싱 이전에 리베이스가 필요할 수 있으나, 스쿼싱 자체가 리베이스와 동등하게 간주될 수 있습니다.

CI/CD 파이프라인 없이 리베이스

CI/CD 파이프라인을 트리거하지 않고 Merge Request 브랜치를 리베이스하려면, Merge Request 보고서 섹션에서 파이프라인 없이 리베이스를 선택합니다.

이 옵션은:

  • 빠른-앞으로 Merge이 불가능하지만 충돌이 없는 리베이스가 가능한 경우에 사용 가능합니다.
  • 파이프라인 성공이 필요함 옵션이 활성화되어 있지 않은 경우에는 사용할 수 없습니다.

CI/CD 파이프라인 없는 리베이스는 자주 리베이스가 필요한 반선형 워크플로우를 갖는 프로젝트에서 리소스를 절약합니다.

관련 주제