병합 방법

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

프로젝트에서 선택한 병합 방법은 병합 요청의 변경 내용이 기존 브랜치에 어떻게 병합되는지를 결정합니다.

이 페이지의 예시는 main 브랜치가 A, C, E 커밋을 가지고 있는 상태에서, feature 브랜치에 B와 D 커밋이 있는 것을 가정하고 있습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% gitGraph accTitle: 병합 다이어그램 accDescr: 두 브랜치에 있는 다섯 개의 커밋에 대한 Git 그래프이며, 이후 페이지의 다른 그래프에서 확장됩니다. commit id: "A" branch feature commit id: "B" commit id: "D" checkout main commit id: "C" commit id: "E"

프로젝트의 병합 방법 구성

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 병합 요청을 선택합니다.
  3. 이 옵션 중에서 원하는 병합 방법을 선택합니다:
    • 병합 커밋 (Merge commit)
    • 반선형 히스토리를 가진 병합 커밋 (Merge commit with semi-linear history)
    • 빨리 감기 병합 (Fast-forward merge)
  4. 병합 시 커밋 스쿼시에서 커밋을 처리하는 기본 동작을 선택합니다:
    • 허용하지 않음: 스쿼싱은 영원히 수행되지 않으며 사용자는 동작을 변경할 수 없습니다.
    • 허용: 스쿼싱은 기본적으로 꺼져 있지만 사용자가 동작을 변경할 수 있습니다.
    • 권장: 스쿼싱은 기본적으로 켜져 있지만 사용자가 동작을 변경할 수 있습니다.
    • 요구: 스쿼싱은 항상 수행되며 사용자는 동작을 변경할 수 없습니다.
  5. 변경 사항 저장을 선택합니다.

병합 커밋

기본적으로 GitLab은 브랜치를 main에 병합할 때 병합 커밋을 생성합니다. 커밋이 병합 시 스쿼싱되었는지 여부에 상관없이 별도의 병합 커밋이 항상 생성됩니다. 이 전략은 main 브랜치에 스쿼싱 된 커밋과 병합 커밋이 모두 추가될 수 있습니다.

이 다이어그램은 병합 커밋 전략을 사용하는 경우, feature 브랜치가 main으로 병합되는 방식을 보여줍니다. 이는 GitLab UI에서 Merge method로 Merge commit을 선택한 것과 동등합니다:

  • 피처 브랜치가 Merge commit 방식으로 병합된 후, main 브랜치가 다음과 같아 보입니다:

    %%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%% gitGraph accTitle: 병합 커밋 다이어그램 accDescr: 피처 브랜치가 병합될 때 GitLab에서 병합 커밋이 어떻게 생성되는지 보여주는 Git 그래프 commit id: "A" branch feature commit id: "B" commit id: "D" checkout main commit id: "C" commit id: "E" merge feature

  • 반면에 스쿼시 병합은 feature 브랜치의 모든 커밋의 가상 복사본인 스쿼시 커밋을 만듭니다. 원래의 커밋 (B와 D)은 feature 브랜치에서 변경되지 않은 채로 유지되며, 그 후 main 브랜치에 병합 커밋이 만들어집니다:

    %%{init: { 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%% gitGraph accTitle: 스쿼시 병합 다이어그램 accDescr: 스쿼시 커밋이 메인 브랜치에 추가된 후 저장소와 브랜치 구조를 보여주는 Git 그래프 commit id:"A" branch feature checkout main commit id:"C" checkout feature commit id:"B" commit id:"D" checkout main commit id:"E" branch "B+D" commit id: "B+D" checkout main merge "B+D"

스쿼시 병합 그래프는 GitLab UI에서 다음 설정과 동등합니다: - 병합 방법: 병합 커밋. - 병합 시 스쿼싱 커밋: 요구 사항 설정. - 또한 스쿼시 병합 그래프는 다음 명령어와 동등합니다: 

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

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

병합마다 병합 커밋이 생성되지만, 브랜치는 빨리 감기 병합이 가능한 경우에만 병합됩니다. 이는 병합 요청 빌드가 성공한 경우, 병합 후 대상 브랜치 빌드 또한 성공함을 보장합니다. 이 병합 방식을 사용하여 생성된 예시 커밋 그래프:

%%{init: { "fontFamily": "GitLab Sans" }}%% gitGraph accTitle: 병합 커밋 다이어그램 accDescr: 병합 커밋 시 커밋 흐름을 보여주는 커밋 그래프 commit id: "Init" 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: "Squashed commits" checkout main merge squash-mr

반선형 히스토리를 가진 병합 커밋 메소드를 선택한 경우 병합 요청 페이지를 방문할 때, 빨리 감기 병합이 가능한 경우에만 수락할 수 있습니다. 빨리 감기 병합이 불가능한 경우 사용자에게 rebase 옵션을 제공합니다. 이 방법은 병합 커밋 방법과 같은 Git 명령어와 동등합니다. 그러나, 소스 브랜치가 대상 브랜치(예: main)의 오래된 버전을 기반으로 할 때는, 소스 브랜치를 rebase해야 합니다. 이 병합 방법은 더 깔끔한 히스토리를 만들면서도 어느 브랜치에서 시작되었는지와 어디에 병합되었는지를 여전히 볼 수 있게 합니다.

파스트 포워드 병합

가끔씩 작업 흐름 정책은 병합 커밋 없이 깨끗한 커밋 히스토리를 요구할 수 있습니다. 이러한 경우에는 파스트 포워드 병합이 적절합니다. 파스트 포워드 병합 요청을 통해 선형적인 Git 히스토리를 유지하면서 병합 커밋을 생성하지 않고 병합 요청을 수락할 수 있습니다. 이 병합 방법을 사용하여 생성된 예시 커밋 그래프:

%%{init: { "fontFamily": "GitLab Sans" }}%% gitGraph accTitle: 파스트 포워드 병합 다이어그램 accDescr: 파스트 포워드된 병합 요청이 선형적인 Git 히스토리를 유지하지만 병합 커밋을 추가하지 않는 방법을 보여줍니다. commit id: "Init" commit id: "mr-branch-1 병합" commit id: "mr-branch-2 병합" commit id: "main 브랜치에 커밋" commit id: "스쿼시 병합"

이 방법은 다음과 동등합니다:

  • 일반적인 병합의 경우 git merge --ff <소스 브랜치>.
  • 스쿼시 병합의 경우 git merge --squash <소스 브랜치> 후 git commit.

파스트 포워드 병합 (--ff-only) 설정이 활성화되면 병합 커밋이 생성되지 않고 모든 병합이 파스트 포워드됩니다. 브랜치를 파스트 포워드할 수 있는 경우에만 병합이 허용됩니다. 파스트 포워드 병합이 불가능한 경우에는 유저가 리베이스를 선택할 수 있는 옵션이 제공됩니다. 자세한 내용은 Rebasing in (semi-)linear merge methods을 참조하세요.

파스트 포워드 병합 방법이 선택된 병합 요청 페이지를 방문할 때, 파스트 포워드 병합이 가능한 경우에만 이를 수락할 수 있습니다.

(반순) 선형 병합 방법에서 리베이스하기

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

  • (반순) 선형 히스토리로 병합 커밋
  • 파스트 포워드 병합

파스트 포워드 병합이 불가능하지만 충돌이 없는 리베이스가 가능한 경우, GitLab은 다음을 제공합니다:

파스트 포워드 병합하기 전에 소스 브랜치를 로컬에서 리베이스해야 합니다 만약 다음 두 조건이 모두 참이면:

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

스쿼시하기 전에 리베이스할 수 있음에도 불구하고, 스쿼시 자체가 리베이스와 동등하게 간주될 수 있습니다.

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

CI/CD 파이프라인을 트리거하지 않고 병합 요청의 브랜치를 리베이스하려면, 병합 요청 보고서 섹션에서 CI/CD 파이프라인 없이 리베이스를 선택하세요.

이 옵션은 다음과 같습니다:

  • 파스트 포워드 병합이 불가능하고 충돌이 없는 리베이스가 가능한 경우에 사용할 수 있습니다.
  • 파이프라인이 성공해야 한다 옵션이 활성화된 경우에는 사용할 수 없습니다.

CI/CD 파이프라인 없이 리베이스하는 것은 자주 리베이스가 필요한 반순 선형 작업 흐름을 가진 프로젝트에서 리소스를 저장하는 데 도움이 됩니다.

관련 토픽