architecture · high priority
Git 워크플로우 — 실무 브랜칭 전략
Git Flow, GitHub Flow, Trunk-Based — 팀에 맞는 전략 선택
basic 난이도2시간토스당근카카오네이버배민쿠팡라인
시작 전
이해도
매우 낮음
학습 개요
탄생 배경
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“문서 편집 방식”
merge는 두 버전의 문서를 합쳐서 "두 버전을 합침"이라는 메모와 함께 보관합니다. rebase는 마치 내 수정사항이 처음부터 최신 문서에서 작성된 것처럼 재작성합니다. 결과는 같지만 히스토리가 다릅니다.
핵심 개념
브랜칭 전략 비교
| 전략 | 브랜치 수 | 릴리즈 | 적합한 팀 |
|---|---|---|---|
| Git Flow | 많음 (main/develop/feature/release/hotfix) | 버전 기반 (v1.0, v1.1) | 릴리즈 주기가 정해진 앱, 여러 버전 유지 |
| GitHub Flow | 적음 (main + feature) | CI/CD 자동화 | 웹 서비스, 작은 팀, 잦은 배포 |
| Trunk-Based | 최소 (main만) | 피처 플래그 활용 | 고성숙 CI/CD, 대규모 팀 |
현실 조언
스타트업, 웹 서비스는 GitHub Flow(main + feature 브랜치)가 가장 많이 쓰입니다. 복잡한 Git Flow는 오히려 배포 속도를 늦춥니다. 대기업도 Trunk-Based로 이동하는 추세입니다.
실무 적용
어떤 상황에서 사용하는가
PR 기반 개발 플로우에서 최신 main 반영
어떻게 적용하는가
feature 브랜치에서 git fetch origin && git rebase origin/main으로 최신 변경사항을 반영합니다. 충돌 해결 후 force push로 PR을 업데이트합니다. 병합 시 squash merge로 feature의 여러 커밋을 하나로 압축합니다.
흔한 실수와 안티패턴
- 공유 브랜치에 force push — 절대 금지
- main에 직접 커밋 — PR 프로세스 우회
- 너무 큰 PR — 리뷰 어려움, 충돌 가능성 높음
- git pull 대신 git pull --rebase 사용하면 더 깔끔한 히스토리
면접 질문
기초토스당근카카오네이버배민쿠팡라인
답변 방향 힌트
히스토리 보존 vs 선형화, 황금 규칙
반드시 언급할 키워드
- merge: 히스토리 보존, merge commit 생성
- rebase: 선형 히스토리, 커밋 재작성
- 공유 브랜치 rebase 금지
예상 꼬리 질문
- git reflog는 어떤 상황에서 사용하나요?
- GitHub의 Protected Branch 설정으로 어떤 것들을 강제할 수 있나요?