병합 방법

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

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

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

병합 다이어그램두 브랜치에 있는 다섯 개의 커밋에 대한 Git 그래프이며, 이후 페이지의 다른 그래프에서 확장됩니다.mainfeatureABDCE

프로젝트의 병합 방법 구성

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

병합 커밋

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

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

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

    병합 커밋 다이어그램피처 브랜치가 병합될 때 GitLab에서 병합 커밋이 어떻게 생성되는지 보여주는 Git 그래프mainfeatureABDCE
  • 반면에 스쿼시 병합feature 브랜치의 모든 커밋의 가상 복사본인 스쿼시 커밋을 만듭니다. 원래의 커밋 (B와 D)은 feature 브랜치에서 변경되지 않은 채로 유지되며, 그 후 main 브랜치에 병합 커밋이 만들어집니다:

    스쿼시 병합 다이어그램스쿼시 커밋이 메인 브랜치에 추가된 후 저장소와 브랜치 구조를 보여주는 Git 그래프mainfeatureB+DACBDEB+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

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

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

병합 커밋 다이어그램병합 커밋 시 커밋 흐름을 보여주는 커밋 그래프mainmr-branch-1mr-branch-2squash-mrInit1-b733d712-54150514-f29b40c5-ebbc52e7-e795874Squashed commits

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

파스트 포워드 병합

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

파스트 포워드 병합 다이어그램파스트 포워드된 병합 요청이 선형적인 Git 히스토리를 유지하지만 병합 커밋을 추가하지 않는 방법을 보여줍니다.mainInitmr-branch-1 병합mr-branch-2 병합main 브랜치에 커밋스쿼시 병합

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

  • 일반적인 병합의 경우 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 파이프라인 없이 리베이스하는 것은 자주 리베이스가 필요한 반순 선형 작업 흐름을 가진 프로젝트에서 리소스를 저장하는 데 도움이 됩니다.

관련 토픽