브랜치 전략 & PR 흐름 — Trunk-based · GitHub Flow
Git Flow는 과했다. 2026년 바이브코더에겐 Trunk-based 또는 GitHub Flow가 답.
"언제 브랜치 따고 언제 머지하나"의 규칙이 없으면 AI와 협업에서도 충돌·혼란이 쌓인다. 단순한 규칙 한 세트면 됨.
과거엔 Git Flow(develop·release·hotfix 등 복잡) 유행이었지만, 2020년대는 단순화. Trunk-based와 GitHub Flow가 표준. AI가 머지·릴리스를 자동화하는 지금 특히 유효.
| 전략 | 뜻 | 어울리는 팀 |
|---|---|---|
| Trunk-Based | 모두 main에 자주 작은 커밋 (수시~일 단위 머지) | 고성능 팀, CI 강함 |
| GitHub Flow | main + 짧은 feature 브랜치 → PR → 머지 | 바이브코더·소규모 (추천) |
| Git Flow (옛날) | develop/release/hotfix 다층 | 대기업·릴리스 주기 긴 |
# GitHub Flow — 바이브코더 기본 루프
# 1) main에서 브랜치 만들기
git checkout main && git pull
git checkout -b feat/add-login
# 2) Claude와 작업 + 작은 커밋 여러 개
git add . && git commit -m "feat: 로그인 폼 UI"
git add . && git commit -m "feat: 로그인 API 연결"
# 3) 푸시 + PR
git push -u origin feat/add-login
gh pr create --fill # GitHub CLI
# 4) CI 초록 + 리뷰 통과 → 머지 (Squash and Merge 권장)
gh pr merge --squash --delete-branch
# 5) 로컬 main 정리
git checkout main && git pull && git branch -d feat/add-loginPR마다 Vercel Preview URL이 자동 생성 → 리뷰어가 실제 UI로 확인. 머지는 Squash(feature 커밋들이 main에 한 커밋으로)가 2026년 표준.
작은 PR 원칙. 200줄 이하, 하나의 변경. 리뷰·롤백·AI가 생성한 diff 검토 모두 쉬워진다. 큰 PR이 쌓이면 머지 지옥 + 충돌 + Claude도 맥락 못 잡음.
브랜치 네이밍 관례. `feat/...` 기능, `fix/...` 버그, `chore/...` 잡일, `refactor/...` 리팩토링, `docs/...` 문서. 커밋 메시지도 같은 prefix + Conventional Commits(`feat:`·`fix:`·`chore:`) 쓰면 자동 changelog·버전 관리 가능(semantic-release).
# 좋은 커밋 메시지 (Conventional Commits)
feat: 로그인에 Google OAuth 추가
fix(auth): JWT 만료 시 refresh 흐름 누락 수정
chore(deps): next 16.1.6 업그레이드
refactor(user): Repository 패턴으로 분리
docs: README에 Supabase 설정 단계 보강
# 안 좋은 커밋
update
수정함
fix bug
작업중Claude에게도 "Conventional Commits 형식으로 커밋 메시지 써줘" 한 줄이면 일관성 달성.
Feature Flag(기능 플래그)를 쓰면 main에 코드를 미리 머지해두고 스위치로만 켜기. 미완 기능을 병합해도 사용자엔 안 보임. LaunchDarkly·Flagsmith 등. 대규모 팀의 Trunk-Based가 가능한 이유.
2026년 바이브코더에게 권장되는 단순 브랜치 전략 이름은?
커밋 메시지에 `feat:`·`fix:`·`chore:` 같은 접두사를 붙이는 표준의 이름은?