프로젝트에 선택한 머지 방법에 따라 머지 리퀘스트의 변경 사항이 기존 브랜치에 머지되는 방식이 결정됩니다.

이 페이지의 예시는 커밋 A, C, E가 있는 main 브랜치와 커밋 B, D가 있는 feature 브랜치를 전제로 합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
   accTitle: Diagram of a merge
   accDescr: A Git graph of five commits on two branches, which will be expanded on in other graphs in this page.
   commit id: "A"
   branch feature
   commit id: "B"
   commit id: "D"
   checkout main
   commit id: "C"
   commit id: "E"

프로젝트의 머지 방법 구성#

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. 다음 옵션 중에서 원하는 Merge method를 선택합니다.
   • Merge commit
   • Merge commit with semi-linear history
   • Fast-forward merge
4. Squash commits when merging에서 커밋 처리 기본 동작을 선택합니다.
   • Do not allow: 스쿼시를 수행하지 않으며, 사용자가 동작을 변경할 수 없습니다.
   • Allow: 스쿼시가 기본적으로 꺼져 있으며, 사용자가 동작을 변경할 수 있습니다.
   • Encourage: 스쿼시가 기본적으로 켜져 있으며, 사용자가 동작을 변경할 수 있습니다.
   • Require: 스쿼시를 항상 수행하며, 사용자가 동작을 변경할 수 없습니다.
5. Save changes를 선택합니다.

머지 커밋#

기본적으로 GitLab은 브랜치를 main에 머지할 때 머지 커밋을 만듭니다. 머지 시 스쿼시 여부와 관계없이 별도의 머지 커밋이 항상 생성됩니다. 이 전략을 사용하면 main 브랜치에 스쿼시 커밋과 머지 커밋이 모두 추가될 수 있습니다.

다음 다이어그램은 Merge commit 전략을 사용할 때 feature 브랜치가 main에 머지되는 방식을 보여 줍니다. 이는 git merge --no-ff <feature> 명령을 실행하고, GitLab UI에서 Merge method로 Merge commit을 선택한 것과 동일합니다.

• Merge commit 방법으로 기능 브랜치를 머지하면 main 브랜치는 다음과 같습니다.

  Mermaid 다이어그램 (12줄)

  소스 코드 보기

  %%{init: { 'gitGraph': {'logLevel': 'debug', 'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%%
  gitGraph
     accTitle: Diagram of a merge commit
     accDescr: A Git graph showing how merge commits are created in GitLab when a feature branch is merged.
     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 브랜치에 머지 커밋이 생성됩니다.

  Mermaid 다이어그램 (17줄)

  소스 코드 보기

  %%{init: { 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'main', 'fontFamily': 'GitLab Sans'}} }%%
  gitGraph
     accTitle: Diagram of a squash merge
     accDescr: A Git graph showing repository and branch structure after a squash commit is added to the main branch.
     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의 다음 설정과 동일합니다.

• Merge method: Merge commit.
• Squash commits when merging은 다음 중 하나로 설정합니다.
  • Require.
  • Allow 또는 Encourage로 설정하고, 머지 리퀘스트에서 스쿼시를 선택합니다.

스쿼시 머지 그래프는 다음 명령과도 동일합니다.

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

스쿼시 머지 이후에도 오래 유지되는 소스 브랜치에서 작업을 계속하면, 이후 머지 리퀘스트에 이미 머지된 커밋과 소스 브랜치가 대상 브랜치보다 뒤처져 있다는 경고가 표시될 수 있습니다. 자세한 내용은 장기 브랜치 동작을 참고합니다.

반선형 기록이 있는 머지 커밋#

머지할 때마다 머지 커밋이 생성되지만, fast-forward 머지가 가능한 경우에만 브랜치가 머지됩니다. 이로써 머지 리퀘스트 빌드가 성공했다면 머지 후 대상 브랜치 빌드도 성공합니다. 이 머지 방법으로 생성되는 커밋 그래프 예시는 다음과 같습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Diagram of a merge commit with semi-linear history
  accDescr: Shows the flow of commits when a branch merges with a merge commit and semi-linear history.
  commit id: "Init"
  branch mr-branch-1
  commit id: "B"
  commit id: "C"
  checkout main
  merge mr-branch-1
  branch mr-branch-2
  commit id: "D"
  commit id: "E"
  checkout main
  merge mr-branch-2
  commit id: "F"
  branch squash-mr
  commit id: "Squashed commits"
  checkout main
  merge squash-mr

Merge commit with semi-linear history 방법을 선택한 상태로 머지 리퀘스트 페이지를 열면 fast-forward 머지가 가능한 경우에만 머지할 수 있습니다. fast-forward 머지가 불가능하면 리베이스 옵션이 제공됩니다. (반)선형 머지 방법에서의 리베이스를 참고합니다.

이 방법은 Merge commit 방법과 동일한 Git 명령에 대응합니다. 다만 소스 브랜치가 대상 브랜치(예: main)의 오래된 버전을 기준으로 하고 있다면 소스 브랜치를 리베이스해야 합니다. 이 머지 방법은 각 브랜치가 어디에서 시작하고 머지되었는지 확인할 수 있으면서도 더 깔끔한 기록을 만듭니다.

Fast-forward 머지#

워크플로 정책상 머지 커밋 없이 깔끔한 커밋 기록을 유지해야 하는 경우가 있습니다. 이런 경우에는 fast-forward 머지가 적합합니다. fast-forward 머지 리퀘스트를 사용하면 머지 커밋을 만들지 않고 선형 Git 기록을 유지할 수 있습니다.

fast-forward 머지는 대상 브랜치(예: main)가 소스 브랜치의 기준 커밋에서 분기하지 않은 경우에만 가능합니다. 대상 브랜치에 소스 브랜치에는 없는 새 커밋이 있다면 먼저 소스 브랜치를 리베이스해야 합니다.

fast-forward 머지 (--ff-only) 설정이 활성화되어 있으면 브랜치를 fast-forward 할 수 있을 때만 머지가 허용됩니다. fast-forward 머지가 불가능하면 리베이스 옵션이 제공됩니다. 자세한 내용은 (반)선형 머지 방법에서의 리베이스를 참고합니다.

스쿼시 없음#

스쿼시가 비활성화되어 있으면 소스 브랜치의 모든 커밋이 개별 커밋 기록을 유지한 채 대상 브랜치에 그대로 추가됩니다.

머지 전, main은 커밋 A에 있고 feature에는 커밋 B, C, D가 있는 상태입니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Branch state before fast-forward merge
  accDescr: Shows main branch at commit A, with feature branch containing commits B, C, and D.
  commit id: "A (main)"
  branch feature
  commit id: "B"
  commit id: "C"
  commit id: "D"

fast-forward 머지 후에는 기능 브랜치의 모든 커밋이 포함되어 main 이 커밋 D를 가리킵니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Result after fast-forward merge without squashing
  accDescr: Shows linear history with all individual commits B, C, and D now on main branch.
  commit id: "A"
  commit id: "B"
  commit id: "C"
  commit id: "D (main)"

이 방법은 git merge --ff-only <source-branch>와 동일합니다.

스쿼시 포함#

스쿼시가 활성화되어 있으면 소스 브랜치의 모든 커밋이 먼저 하나의 커밋으로 합쳐진 다음 대상 브랜치로 fast-forward 됩니다.

머지 전, main은 커밋 A에 있고 feature에는 커밋 B, C, D가 있는 상태입니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Branch state before fast-forward merge with squashing
  accDescr: Shows main branch at commit A, with feature branch containing commits B, C, and D.
  commit id: "A (main)"
  branch feature
  commit id: "B"
  commit id: "C"
  commit id: "D"

스쿼시를 포함한 fast-forward 머지 후에는 B, C, D의 모든 변경 사항을 담은 커밋 하나가 main에 포함됩니다.

%%{init: { "fontFamily": "GitLab Sans" }}%%
gitGraph
  accTitle: Result after fast-forward merge with squashing
  accDescr: Shows linear history with commits B, C, and D combined into one squashed commit on main branch.
  commit id: "A"
  commit id: "B+C+D (main)"

이 방법은 git merge --squash <source-branch>를 실행한 뒤 git commit을 실행하는 것과 동일합니다.

(반)선형 머지 방법에서의 리베이스#

다음 머지 방법에서는 소스 브랜치가 대상 브랜치와 최신 상태로 맞춰져 있을 때만 머지할 수 있습니다.

• 반선형 기록이 있는 머지 커밋.
• Fast-forward 머지.

fast-forward 머지는 불가능하지만 충돌 없는 리베이스가 가능하면 GitLab은 다음을 제공합니다.

• /rebase 빠른 작업.
• 사용자 인터페이스에서 Rebase를 선택하는 옵션.

다음 두 조건이 모두 참이면 fast-forward 머지 전에 소스 브랜치를 로컬에서 리베이스해야 합니다.

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

스쿼시 자체를 리베이스와 동등하게 볼 수 있더라도, 스쿼시 전에 리베이스가 필요할 수 있습니다.

머지 전 자동 리베이스#

Merge commit with semi-linear history 또는 Fast-forward merge 방법을 사용할 때 머지 전 자동 리베이스를 켤 수 있습니다. 이 설정을 켜면 소스 브랜치가 대상 브랜치보다 뒤처져 있을 때 GitLab 이 머지 시점에 소스 브랜치를 대상 브랜치 위로 자동으로 리베이스합니다. 머지 전에 직접 리베이스하거나 리베이스가 끝날 때까지 기다리지 않아도 됩니다.

서버 측 리베이스는 커밋에서 GPG 서명을 제거합니다. 프로젝트에 서명된 커밋이 필요하다면 자동 리베이스가 적절한지 검토합니다.

자동 리베이스의 동작은 다음과 같습니다.

• 원래 소스 브랜치를 수정하지 않고 소스 브랜치를 서버 측에서 리베이스합니다.
• 리베이스된 커밋이 포함되도록 대상 브랜치를 fast-forward 합니다.
• 리베이스된 결과에 대해 CI/CD 파이프라인을 다시 실행하지 않습니다.
• 머지 충돌 없이 리베이스가 완료될 수 있어야 합니다.

머지 전 자동 리베이스 켜기#

사전 요구 사항:

• 프로젝트에 대한 Maintainer 또는 Owner 권한.
• 프로젝트 머지 방법이 Merge commit with semi-linear history 또는 Fast-forward merge로 설정되어 있어야 합니다.

자동 리베이스를 켜려면 다음 절차를 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Merge requests를 선택합니다.
3. Merge method 섹션에서 Enable automatic rebase prior to merge를 선택합니다.
4. Save changes를 선택합니다.

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

CI/CD 파이프라인을 트리거하지 않고 머지 리퀘스트 브랜치를 리베이스하려면 머지 리퀘스트 보고서 섹션에서 Rebase without pipeline을 선택합니다.

이 옵션의 조건은 다음과 같습니다.

• fast-forward 머지는 불가능하지만 충돌 없는 리베이스가 가능할 때 제공됩니다.
• Pipelines must succeed 옵션이 활성화되어 있으면 제공되지 않습니다.

CI/CD 파이프라인 없이 리베이스하면 잦은 리베이스가 필요한 반선형 워크플로 프로젝트에서 리소스를 절약할 수 있습니다.

관련 주제#

• 스쿼시 및 머지