프로젝트에 대해 선택하는 머지 방법은 머지 리퀘스트의 변경 사항이 기존 브랜치에 어떻게 머지되는지를 결정합니다.

이 페이지의 예시는 커밋 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 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 머지 후, main은 이제 B, C, D의 모든 변경 사항을 포함하는 단일 커밋을 포함합니다:

%%{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 파이프라인 없는 리베이스는 빈번한 리베이스가 필요한 반선형 워크플로우를 사용하는 프로젝트에서 리소스를 절약합니다.

관련 항목#

• 스쿼시 및 머지