“우리 팀은 squash merge를 써야 할까, merge commit을 써야 할까?” PR 병합 버튼 앞에서 한 번쯤 망설여보셨을 겁니다. squash merge merge commit 차이는 단순히 취향 문제가 아니라, 브랜치 단계별로 답이 달라지는 실무 고민입니다.
저희 팀도 커밋·배포 목록을 깔끔하게 유지하고 싶다는 목표로 squash merge merge commit 차이를 실제로 비교해봤고, feature→dev와 release→main 두 구간에 서로 다른 방식을 적용하기로 확정했습니다.
이 글에서는 두 방식의 차이, 왜 구간마다 다른 방식을 쓰는 게 업계 일반 관행과도 맞는지, 그리고 확정한 배포 흐름을 실제 명령어로 정리합니다.
📌 한눈에 보는 squash merge merge commit 차이
squash merge와 merge commit의 차이는 커밋 단위 보존 여부, 히스토리 가독성, 되돌리기(revert) 편의성이 핵심인 PR 병합 방식 선택 기준입니다.
Squash merge와 Merge commit, 정확히 뭐가 다른가?
Squash merge는 PR 안의 여러 커밋을 하나로 합쳐서 남기는 방식입니다. PR 하나 = 최종 커밋 하나가 되니, 리뷰 중 오간 “오타 수정”, “다시 확인” 같은 자잘한 커밋들이 대상 브랜치 히스토리에 남지 않습니다.
Merge commit은 PR의 모든 개별 커밋을 그대로 유지한 채, 병합됐다는 사실을 나타내는 커밋 하나를 추가로 남기는 방식입니다. 브랜치가 어느 시점에 갈라졌다가 다시 합쳐졌는지, 그 구조 자체가 히스토리에 보존됩니다.
개인적으로는 이유를 하나로 뭉뚱그리기보다, “무엇을 보존하고 싶은가”로 구분하는 게 명확하다고 봅니다. PR 단위의 깔끔한 기록이 목적이면 squash, 병합 구조 자체의 이력이 목적이면 merge commit입니다.
왜 feature→dev는 squash, release→main은 merge commit일까?
실제로 이 조합을 확정하면서 느낀 건, 두 단계의 목적이 완전히 다르다는 점입니다. feature→dev는 squash로 PR 단위 기록만 남기면 되고, release→main은 반대로 “이번 배포에 어떤 feature들이 들어갔는지”를 개별 단위로 보존하는 게 목적입니다. release 브랜치를 merge commit으로 합치면, dev에 쌓여있던 feature별 squash 커밋들이 그대로 main에 남고 배포 시점을 표시하는 merge 커밋 하나가 추가되는 구조라 가독성이 가장 좋습니다.
📊 일반적으로도 이 조합이 맞을까?
업계 전반의 경향으로 보면, feature → 통합 브랜치(dev) 구간은 squash merge가 최근 표준에 가깝고, release → main 구간은 merge commit 비중이 여전히 더 높습니다. release 브랜치라는 개념 자체를 쓰는 팀은 “release 이력을 보존”하는 게 목적이라 이 단계에서 squash를 쓰면 오히려 정보 손실이 생기기 때문입니다.
확정된 배포 흐름, 명령어로 확인해봅니다
지금까지 정리한 내용을 실제 배포 흐름에 적용하면 다음과 같습니다: ① dev에서 PR 브랜치 생성 → ② 작업 후 푸시 → ③ PR을 squash merge로 dev에 반영 → ④ 배포 시점에 main 기준으로 release 브랜치 생성 → ⑤ dev를 release 브랜치에 merge → ⑥ release 브랜치 푸시 → ⑦ release → main PR을 merge commit으로 병합.
📎 새 작업 시작 → 배포까지, 명령어 순서
1. 새 작업 시작 (dev 기준 새 브랜치) git fetch origin git checkout -b JIRA-123 origin/dev 2. 작업 → 커밋 → 푸시 git add . git commit -m "✨ JIRA-123 기능 구현" git push origin JIRA-123 3. PR 생성 (JIRA-123 → dev) → 팀장 승인 후 Squash and merge 4. 배포 시점, main 기준 release 브랜치 생성 git fetch origin git checkout -b release/260710_1500 origin/main 5. dev를 release 브랜치에 merge git merge origin/dev 6. release 브랜치 푸시 git push origin release/260710_1500 7. PR 생성 (release/260710_1500 → main) → Merge commit 방식으로 병합 (Squash 아님)
개인적으로는 이 구조에서 가장 신경 써야 할 디테일이 하나 있다고 봅니다. GitHub PR 화면의 병합 방식이 저장소 기본값으로 Squash 하나만 고정돼 있으면, release → main PR도 실수로 squash 되어버릴 수 있습니다. 저장소 설정에서 Squash와 Merge commit을 모두 허용해두고, release PR을 올릴 때마다 병합 방식을 수동으로 “Create a merge commit”으로 선택하는 습관을 들이는 게 안전합니다.
Main에 merge commit을 쓰면 커밋이 많아져서 복잡해지지 않을까?
결론부터 말하면, 복잡해지는 건 충돌이나 관리 부담이 아니라 로그에 찍히는 줄 수뿐입니다. release 브랜치는 dev를 merge해서 만든 것이고, dev에는 feature PR들이 이미 squash 커밋 1개씩으로 정리돼 있습니다. 이걸 merge commit으로 main에 합치면, main 로그에는 merge commit 1개와 그 안에 들어있던 feature별 squash 커밋들이 그대로 남습니다.
실제로 진짜 복잡해지는 경우는 따로 있습니다. git log --graph로 그래프 형태를 볼 때, release가 자주 있거나 도중에 main에 hotfix가 끼어들면 분기가 여러 개 겹쳐 시각적으로 어수선해질 수 있습니다. 이건 merge commit 자체의 한계라기보다 그래프 뷰의 특성에 가깝습니다.
릴리즈 태깅을 날짜+시간 기반(예: Release/260708_1803)으로 하고 계시다면, 태그 시점에 “이번 릴리즈에 포함된 PR 목록”을 자동으로 뽑아주는 스크립트 하나만 추가해도 배포 노트 작성 부담이 크게 줄어듭니다. 예를 들어 git log <이전태그>..<현재태그> --oneline 한 줄이면 squash merge로 정리된 PR 단위 커밋 목록이 그대로 배포 노트 초안이 됩니다.
📱 복잡함을 줄이는 로그 확인 습관
평소엔 git log --oneline main으로 플랫하게 확인하고, 브랜치 구조 자체를 봐야 할 때만 --graph를 쓰는 식으로 구분하는 걸 권장합니다.
릴리즈 태그를 남기고 있다면 태그 구간만 잘라보는 습관을 들이면 체감 복잡도가 거의 사라집니다.
1차 PR이 이미 squash merge로 dev에 들어간 뒤 후속 수정이 생겼다면
이미 배포된 Jira 브랜치에 후속 수정이 생겼을 때 보러가기 →🧾 정리하며
squash merge merge commit 차이는 결국 “무엇을 보존할 것인가”의 문제입니다. feature→dev는 PR 단위 기록을 위해 squash, release→main은 배포 단위 기록을 위해 merge commit — 이렇게 구간별로 목적에 맞춰 나누는 게 업계 일반 관행과도, 커밋·배포 목록을 깔끔하게 유지하려는 목표와도 잘 맞아떨어집니다.
FAQ — Squash Merge vs Merge Commit 자주 묻는 질문
Q1. Squash merge와 Merge commit의 차이는 무엇인가요?
Squash merge는 PR 안의 여러 커밋을 하나로 합쳐서 남기고, Merge commit은 모든 개별 커밋을 그대로 유지한 채 병합 커밋만 추가합니다.
Q2. 어느 구간에 squash를, 어느 구간에 merge commit을 쓰는 게 좋나요?
feature→dev처럼 PR 단위 기록만 필요한 구간은 squash merge, release→main처럼 배포 단위로 개별 feature 기록을 보존해야 하는 구간은 merge commit이 유리합니다.
Q3. 일반적으로 업계에서는 어떤 방식을 더 많이 쓰나요?
feature→dev 구간은 최근 squash merge가 표준에 가깝고, release→main처럼 배포 브랜치를 최종 브랜치에 합치는 구간은 merge commit 비중이 여전히 더 높습니다.
Q4. Main에 merge commit을 쓰면 커밋이 많아져서 복잡해지지 않나요?
충돌이나 관리 부담이 늘어나는 게 아니라 로그에 찍히는 줄 수만 늘어납니다. git log –oneline으로 플랫하게 보고, 릴리즈 태그 구간만 잘라보는 습관을 들이면 체감 복잡도는 거의 사라집니다.
Q5. Release PR을 올릴 때 병합 방식을 실수하지 않으려면 어떻게 하나요?
저장소 설정에서 Squash와 Merge commit 둘 다 허용해두고, release PR을 올릴 때마다 병합 방식을 수동으로 “Create a merge commit”으로 선택하는 습관을 들이는 게 안전합니다.
Q6. Squash merge를 쓰면 배포 노트 작성이 쉬워지나요?
네. 릴리즈 태그 사이 구간을 git log –oneline으로 확인하면, squash merge로 정리된 PR 단위 커밋 목록이 그대로 배포 노트 초안이 됩니다.
