Merge 메소드

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

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

이 페이지의 예는 main 브랜치에 커밋 A, C, E가 있고, feature 브랜치에 커밋 B와 D가 있다고 가정합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% 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 커밋을 생성합니다. 커밋이 통합할 때 squash되었는지 여부와 상관없이 별도의 Merge 커밋이 항상 생성됩니다. 이 전략은 main 브랜치에 스쿼시 커밋과 Merge 커밋이 모두 추가될 수 있습니다.

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

Merge 전략:

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

Merge 커밋 메소드로 feature 브랜치가 Merge된 후 main 브랜치는 다음과 같이 보입니다:

%%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%% 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', 'fontFamily': 'GitLab Sans'}} }%% 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 메소드로 생성된 예시 커밋 그래프:

%%{init: { "fontFamily": "GitLab Sans" }}%% 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 squash-mr commit id: "스쿼시된 커밋" checkout main merge squash-mr

반 선형 히스토리 Merge 커밋 메소드를 선택하여 Merge Request 페이지를 방문하면, 빠른 전진 Merge이 가능할 때에만 수락할 수 있습니다. 빠른 전진 Merge이 불가능할 때, 사용자는 리베이스 옵션을 선택할 수 있습니다. 자세한 내용은 반 (반)선형 Merge 방법에서 리베이스하기를 참조하십시오.

이 메소드는 Merge 커밋 메소드와 동일한 Git 명령어를 사용합니다. 그러나 소스 브랜치가 대상 브랜치(예: main)의 오래된 버전을 기반으로 하는 경우에는 소스 브랜치를 리베이스해야 합니다. 이 Merge 메소드는 더 깔끔한 히스토리를 생성하면서도 각 브랜치가 어디에서 시작되었고 어디에서 Merge되었는지 확인할 수 있도록 합니다.

빠른 전진 Merge

때로는 워크플로 정책이 Merge 커밋 없이 깨끗한 커밋 히스토리를 요구할 수 있습니다. 이러한 경우, 빠른 전진 Merge이 적합합니다. 빠른 전진 Merge Request을 통해 선형적인 Git 히스토리를 유지하고 Merge 커밋을 만들지 않고 Merge Request을 수락하는 방법을 유지할 수 있습니다. 이 Merge 메소드로 생성된 예시 커밋 그래프:

%%{init: { "fontFamily": "GitLab Sans" }}%% gitGraph commit id: "초기화" commit id: "mr-branch-1 Merge" commit id: "mr-branch-2 Merge" commit id: "main에 커밋" commit id: "스쿼시된 Merge"

이 메소드는 정규 Merge에 대한 git merge --ff <source-branch> 및 스쿼시 Merge에 대한 git merge --squash <source-branch>와 동등합니다.

빠른 전진 Merge(--ff-only 설정이 활성화되면 Merge 커밋이 생성되지 않고 모든 Merge이 빠른 전진되게 됩니다. 빠른 전진 Merge이 불가능할 때, 사용자는 리베이스 옵션을 선택할 수 있습니다. 자세한 내용은 반 선형 Merge 방법에서 리베이스하기를 참조하십시오.

note
빠른 전진 Merge 전략을 사용하는 프로젝트는 Merge 커밋이 생성되지 않기 때문에 배포 날짜로 Merge Request 필터링할 수 없습니다. 또한, 빠른 전진 Merge이 활성화되어 있는 경우 배포-MR 관계에 의존하는 기능이 작동하지 않습니다. 이 버그는 이슈 398611에서 추적되고 있습니다.

빠른 전진 Merge 메소드로 Merge Request 페이지를 방문하면, 빠른 전진 Merge이 가능한 경우에만 수락할 수 있습니다.

빠른 전진 Merge Request

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

이러한 Merge 방법에서는 소스 브랜치가 대상 브랜치와 최신 상태인 경우에만 Merge할 수 있습니다:

  • 반(半)선형 기록과 Merge 커밋
  • 빠른-앞으로 Merge

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

  • /rebase 퀵 액션.
  • 사용자 인터페이스에서 리베이스를 선택할 수 있는 옵션

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

  • 대상 브랜치가 소스 브랜치보다 앞서 있는 경우
  • 충돌이 없는 리베이스가 불가능한 경우

빠른-앞으로 Merge을 위한 로컬 리베이스

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

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

  • 일반 사용 가능하게 된 GitLab 15.3. 피처 플래그 rebase_without_ci_ui가 제거되었습니다.

특정 Merge Request의 브랜치를 리베이스하고자 할 때 CI/CD 파이프라인을 트리거하지 않으려면, Merge Request 보고서 섹션에서 파이프라인 없이 리베이스를 선택하세요.

이 옵션은 다음의 경우에 사용 가능합니다:

  • 빠른-앞으로 Merge이 불가능하지만 충돌이 없는 리베이스가 가능한 경우
  • 파이프라인은 성공해야 함 옵션이 활성화되어 있지 않은 경우

CI/CD 파이프라인 없는 리베이스는 자주 리베이스가 필요한 반(半)선형 워크플로우를 가진 프로젝트에서 리소스를 절약할 수 있습니다.

관련 토픽