GitLab에서 GitHub와 동일한 Squash Merge 만들기

GitLab에서 feature → develop 브랜치를 Squash Merge로 머지했는데,
GitHub와 결과가 달랐다.

깃허브	깃랩

• GitHub
  target 브랜치에 스쿼시 커밋 1개만 생성 😃
• GitLab
  target 브랜치에 스쿼시 커밋 1개 + 머지 커밋 1개 생성 ☹️

깃허브	깃랩

• GitHub
  커밋 메세지: PR 제목(#PR 아이디) + 커밋 목록 😃
• GitLab
  커밋 메세지: 단순 MR 제목 ☹️

깃허브 방식이 마음에 들었기 때문에, 깃랩에 깃허브 방식을 적용한 방법을 정리하려 한다.

1. Squash commit 하나만 남기기

먼저 스쿼시 커밋을 하나만 남기게 설정해보자.

GitLab에서는
Settings → Merge requests → Merge method 에서 머지 방식을 설정할 수 있다.

1️⃣ Merge commit (기본값)

• 항상 머지 커밋 생성
• Squash 시
  👉 Squash 커밋 + Merge 커밋 둘 다 생성

 develop ---o---------M
             \       /
              feature

• 브랜치 구조는 명확
• 히스토리는 쉽게 지저분해짐

2️⃣ Merge commit with semi-linear history

• 항상 머지 커밋 생성
• 단, source 브랜치는 항상 target의 최신 상태여야 함
  (rebase 또는 merge 필수)
• Squash 시 결과는 동일
  👉 Squash 커밋 + Merge 커밋

3️⃣ Fast-forward merge ⭐

• 머지 커밋을 만들지 않음
• 가능한 경우에만 머지
• 충돌 시 rebase 필요 (pull vs pull --rebase)

develop --- A --- B --- C

👉 GitHub Squash Merge와 동일한 결과

결론: 3️⃣ Fast-forward merge

GitHub와 동일한 Squash 결과를 원한다면
Squash Merge + Fast-forward merge 조합이 필요하다.

• 커밋 1개만 남음
• 머지 커밋 없음

대신 주의할 점이 있다ㅠ 번외: Fast-forward 사용 시 주의사항

2. GitHub와 동일한 Squash Commit 메시지 만들기

이번에는 스쿼시 커밋 메세지 템플릿을 수정해서 깃허브 스타일의 스쿼시 커밋 메세지를 적용해보자.

Settings → Merge requests → Squash commit message template에서 설정할 수 있다.

What variables can I use?를 누르면 쓸 수 있는 템플릿 변수들을 볼 수 있다.

적용한 것을 정리해보면

• %{title}: Merge Request 제목
• %{local_reference}: 프로젝트 기준 MR 번호
• %{all_commits}: MR에 포함된 모든 커밋 메시지 (최대 100개)

%{title} (%{local_reference})

%{all_commits}

---

짠 그럼 이전에는 스쿼시 커밋 + 머지 커밋이 생겼던 반면, 이젠 스쿼시 커밋 하나만 생기고 커밋 메세지도 깃허브와 동일하게 적용이 된다.

3. 정리

권장 설정

• Merge method: Fast-forward merge

• Squash commits: 사용

• Default squash commit template:

  %{title} (%{local_reference})
  
  %{all_commits}

운영 전략

• feature → develop
  • Squash + Fast-forward
  • 히스토리 깔끔
• develop → master
  • 머지 커밋이 필요할 때
    👉 Merge method를 Merge commit으로 다시 변경

번외: Fast-forward 사용 시 주의사항

1. develop → master 머지 문제

기본적으로 feature → develop 머지는 squash merge를 사용하고,
develop → main 머지는 일반 merge를 사용하는 경우가 많을 것이다.

하지만 merge commit을 남기지 않기 위해 Fast-forward merge 방식을 설정했다면, develop → main 일반 머지에서도 머지 커밋이 생기지 않는 불상사가 발생한다;;

• feature → develop : 원하는 결과 👍
• develop → master : ❌ 머지 커밋이 남지 않음 (커밋 메시지 편집도 안 뜸)

⚠️Fast-forward merge(edit commit message 안 뜸)	Merge commit(edit commit message 뜸)

---

2. feature 브랜치 관리 방식 강제

Fast-forward는 히스토리가 선형이어야 하므로,

• feature 브랜치에서 develop의 변경 사항을 fetch + merge 방식으로 반영한 경우에는 머지가 불가능하며

• 무조건 rebase 방식으로 히스토리를 정리해야만 squash merge를 진행할 수 있다.

이번 프로젝트에서는 feature 브랜치에서는 항상 pull --rebase로 최신 develop 브랜치 상태를 반영할 것이었기 때문에, 이는 괜찮았지만 (pull vs pull --rebase)

나중에 develop → master로 일반 머지를 하면서 머지 커밋을 남기고 싶을 때는 다시 Merge commit 방법을 적용해야한다는 불편함이 있었다.

---

하지만 나는

• develop 단계에서 커밋 히스토리에 머지 커밋이 남는 게 싫었으며(기능 개발이 활발한 develop 단계에서 매 기능마다 머지 커밋이 섞이니 커밋 히스토리 지저분해짐)

• master 브랜치로 머지를 하는 것은 기능 개발이 모두 끝난 후 한 번만 해줄 것이기 때문에

그냥 Fast-forward 설정을 쓰다가 master 브랜치로 머지할 때만 다시 Merge commit 설정을 해주려 한다.

---

이 방법밖에 없나?? 싶어서 더 찾아봤는데, 이렇게 할 수밖에 없는 것 같다ㅠ

👉 https://gitlab.com/gitlab-org/gitlab/-/issues/1822

이미 오래전부터 제기된 GitLab 이슈다.

내가 봐도 스쿼시 머지임에도 머지 커밋이 생기는 게 말이 안 되는데, 아직도 그대로 가고 있다니ㅠ