퇴근 전에 급하게 고친 버그 하나를 올리려는데, 브랜치는 또 뭘로 파야 하고 PR 승인은 누가 해야 하는지 헷갈렸던 경험, 한 번쯤 있으실 겁니다. “이 정도 규모 팀에 우리 git 브랜치 전략(git pr 정책)이 맞게 짜여 있는 건가?” 하는 고민에서 이 글을 시작했습니다.
저희 팀도 실제로 이런 고민 끝에 지금의 구조로 정착했습니다. main·dev·release 3브랜치 체계, PR 승인 규칙, hotfix 예외 경로까지 — 이번 글은 그 실제 정책을 하나씩 짚어보면서 git 브랜치 전략을 학습·정리해보는 개요 글입니다.
main·dev·release 구조가 왜 이렇게 짜였는지, 승인 규칙이 브랜치마다 왜 다른지, 브랜치 삭제 정책이 없을 때 생기는 문제, 커밋 컨벤션과 릴리즈 태깅까지 순서대로 정리합니다. squash merge와 merge commit의 구체적인 비교, 그리고 이미 배포한 브랜치에 후속 수정이 생겼을 때 rebase·reset·cherry-pick을 다루는 방법은 각각 별도 포스트에서 더 깊이 다룹니다.
📌 한눈에 보는 git 브랜치 전략 핵심
소규모 팀의 git 브랜치 전략은 main·dev·release 3브랜치 구조, PR 승인 범위 최소화, 자동 동기화가 핵심인 2026년 개발 워크플로우입니다.
📎 이 글에서 다루는 내용
- main·dev·release 3브랜치 구조와 각 브랜치의 역할
- PR 승인 규칙(dev는 승인 필요, main은 승인 없음)의 장단점
- 브랜치 삭제 정책이 없을 때 생기는 문제와 해결법
- 날짜 기반 릴리즈 태깅, 이모지 커밋 컨벤션 정리
그럼 우리 팀은 왜 main·dev·release 구조를 쓰기로 했을까?
Git Flow처럼 release·feature·develop·main을 다 나누는 방식도 있지만, 저희 팀은 인원이 적다 보니 브랜치가 많아질수록 오히려 관리 부담이 커진다고 판단해서 dev와 main, 그리고 배포 시점에만 잠깐 만드는 release로 단순화했습니다.
📱 브랜치별 역할 요약
dev: 팀장 승인(submit) 후 머지, 프론트·백엔드가 함께 통합 테스트하는 브랜치
release: dev에서 테스트가 끝난 뒤 main 배포 직전에 따로 만드는 브랜치
main: release 브랜치를 통해 배포되며, hotfix만 예외적으로 승인 없이 바로 반영
핵심은 승인 범위다 — dev는 막고 main은 열어둔 이유
언뜻 보면 거꾸로 된 것처럼 느껴질 수 있습니다. 보통은 “운영 서버로 나가는 main이 더 엄격해야 하는 거 아닌가?” 싶으니까요. 하지만 저희 팀 정책을 뜯어보면 이건 의도된 설계입니다.
dev는 “진행 상황을 팀장이 파악하는 창구” 역할이 큽니다. 코드 리뷰를 적극적으로 하는 팀은 아니지만, 최소한 팀장 승인 1단계를 거치면서 “누가 뭘 작업 중인지”가 자연스럽게 공유됩니다. 반대로 main에 승인 없이 바로 올라가는 경로는 hotfix 전용입니다 — 일반적인 기능 배포는 로컬 작업 → dev 머지(팀장 승인) → 통합 테스트 → release 브랜치 생성 → main 배포 순서를 그대로 따르고, hotfix만 이 release 단계를 건너뛰는 예외 경로인 셈입니다.
개인적으로는 이 구조가 팀 규모(소수 인원, 빠른 의사결정)에는 합리적이라고 봅니다. 다만 전제 조건이 하나 있는데, main에 직접 올라간 hotfix가 dev에도 반영돼야 한다는 점입니다. 이 부분은 이미 GitHub Action으로 main→dev 자동 동기화를 걸어두셨다고 하니, 가장 흔한 실수(hotfix가 dev에 빠져서 다음 배포 때 사라지는 문제) 하나는 이미 해결된 상태입니다.
📱 승인 규칙 한눈에 정리
저희 팀은 feature 개발 → dev 머지(팀장 승인 필요) → 통합 테스트 → release 브랜치 → main 배포 순으로 진행됩니다. hotfix만 이 과정을 건너뛰고 main에 승인 없이 바로 반영되며, main 배포 후에는 GitHub Action이 dev로 자동 동기화합니다.
dev와 main에서 다른 머지 방식을 쓰는 이유가 궁금하다면
Squash Merge vs Merge Commit 완전 정리 보러가기 →머지 후 브랜치를 안 지우면 생기는 3가지 문제
브랜치 삭제 정책이 없는 팀이라면, 이 부분은 방치할수록 체감 불편이 커지는 영역입니다. 첫째, 브랜치 목록이 수십~수백 개로 쌓이면 “지금 살아있는 작업”과 “이미 끝난 작업”을 구분하기 어려워집니다. 둘째, 오래된 브랜치가 dev 최신 상태와 크게 벌어진 채 남아있으면 실수로 그 브랜치에서 다시 작업을 시작하는 일이 생길 수 있습니다. 셋째, 저장소 자체가 무겁게 느껴지고 브랜치 검색·자동완성 속도도 느려집니다.
가장 간단한 해결책은 PR 머지 시 자동 브랜치 삭제 옵션을 켜두는 것입니다. GitHub 기준으로는 저장소 설정(Settings → General → Pull Requests)에서 “Automatically delete head branches” 옵션 하나만 켜면, PR이 머지되는 순간 해당 브랜치가 자동으로 정리됩니다.
📎 브랜치 정리, 이렇게 시작하세요
브랜치 삭제 정책은 PR 머지 시 자동 삭제 → 남아있는 오래된 브랜치는 최근 커밋일 기준으로 일괄 정리 순으로 진행하면 됩니다.
이미 쌓인 브랜치는 git branch -r --merged dev 명령으로 dev에 이미 반영된 브랜치 목록부터 확인하고 정리하는 게 안전합니다.
이모지 커밋 컨벤션 + 날짜 기반 릴리즈 태깅, 실제로 잘 작동하는 조합입니다
커밋 메시지 앞에 이모지를 붙이고 내용은 자유롭게 쓰는 방식은, 엄격한 컨벤션(Conventional Commits 등)만큼 형식적이진 않지만 실무에서 꽤 잘 작동하는 절충안입니다. 이모지만 보고도 “이건 버그 수정, 이건 기능 추가”가 시각적으로 구분되니까요.
릴리즈 태깅을 Release/260708_1803처럼 날짜+시간 기반으로 하시는 것도, 서비스 버전 개념이 딱히 없는 상황에서는 합리적인 선택입니다. 실제로 이 조합(이모지 커밋 + 날짜 태그)을 정리하면서 느낀 건, 규칙이 복잡할 필요는 없다는 점입니다. 소규모 팀에서는 “누가 봐도 바로 이해되는 최소한의 규칙”이 오히려 더 오래 지켜집니다.
📊 지금 단계에서 추가로 정하면 좋은 것
현재 정책이 잘 잡혀있는 팀이라면 PR 머지 후 브랜치 자동 삭제 정도만 추가해도 충분합니다. CI 빌드·테스트가 이미 PR 단계에서 돌아가고 있으니, PR 템플릿에 체크리스트를 넣어 CI 통과 여부를 명확히 하는 것도 함께 고려해볼 만합니다.
🧾 정리하며
저희 팀의 git 브랜치 전략을 실제로 뜯어보니, main·dev·release 구조와 승인 범위 분리(dev만 승인, main은 hotfix 예외), main→dev 자동 동기화까지는 이미 꽤 탄탄하게 잡혀 있었습니다. 남은 건 브랜치 자동 삭제 옵션 정도인데, 설정 몇 개와 팀 내 합의만으로 바로 적용 가능합니다.
학습용으로 정리해보니, 결국 좋은 git 정책이란 “팀 규모에 맞게 최소한의 규칙만 남기고, 그 규칙을 누구나 예외 없이 지키게 만드는 것”이라는 생각이 듭니다. dev/main 사이의 머지 방식 차이와, 이미 배포한 브랜치를 다루는 법은 아래 연결된 글에서 더 깊게 다룹니다.
FAQ — Git 브랜치 전략과 PR 정책 자주 묻는 질문
Q1. Git 브랜치 전략에서 main·dev·release를 나누는 이유는 무엇인가요?
배포된 상태(main), 다음 배포를 준비하는 상태(dev), 배포 직전 임시 상태(release)를 분리하기 위해서입니다. dev에서 충분히 검증한 뒤 release를 거쳐 main으로 배포하면, 운영 서비스에 미완성 코드가 섞이는 걸 막을 수 있습니다.
Q2. PR 승인은 dev와 main 중 어디에 필요한가요?
팀 규모나 정책에 따라 다르지만, 저희 팀은 dev 머지 시에만 팀장 승인을 받고 hotfix는 main에 승인 없이 바로 반영합니다. 긴급 대응 속도를 높이기 위한 구조입니다.
Q3. 머지 후 브랜치를 지우지 않으면 어떻게 되나요?
시간이 지날수록 살아있는 브랜치와 끝난 브랜치를 구분하기 어려워지고, 오래된 브랜치에서 실수로 작업을 재개하는 일이 생길 수 있습니다. PR 머지 시 자동 삭제 옵션을 켜두는 것이 가장 간단한 해결책입니다.
Q4. 릴리즈 태깅은 어떤 기준으로 하는 게 좋나요?
서비스 버전 개념이 명확하다면 v1.2.3 같은 시맨틱 버전이 유리하지만, 버전 개념이 없다면 날짜+시간 기반 태그(예: Release/260708_1803)도 충분히 실용적입니다.
Q5. main에 직접 올린 hotfix가 dev에 반영되지 않으면 어떻게 되나요?
다음 dev→main 배포 때 hotfix 내용이 충돌하거나 다시 사라질 수 있습니다. main→dev 자동 동기화 GitHub Action을 구성해두면 이 문제를 사전에 방지할 수 있습니다.
Q6. 커밋 메시지 컨벤션은 꼭 엄격하게 정해야 하나요?
팀 규모가 작다면 이모지로 유형을 구분하고 내용은 자유롭게 쓰는 간단한 방식도 충분히 작동합니다.
Q7. dev와 main에서 머지 방식(squash/merge commit)을 다르게 쓰나요?
네, 팀에 따라 다르지만 일반적으로 feature→dev는 squash merge, release→main은 merge commit을 쓰는 경우가 많습니다. 자세한 비교는 연결된 포스트에서 다룹니다.
