Git Flow와 GitHub Flow 중 뭘 써야 하나요?

소규모 팀이나 빠른 배포가 필요하면 GitHub Flow, 대규모 팀이나 릴리스 주기가 명확하면 Git Flow를 추천합니다.

커밋 메시지는 어떻게 작성하나요?

Conventional Commits 형식을 추천합니다. "feat: 로그인 기능 추가", "fix: 회원가입 버그 수정" 같은 형식입니다.

PR은 얼마나 자주 만들어야 하나요?

작은 단위로 자주 만드는 것이 좋습니다. 하루 1-2개, 변경 사항 200-400줄 이내가 리뷰하기 적당합니다.

Git 워크플로우 완벽 가이드 | 브랜치 전략부터 협업까지

2026년 3월 31일 · 25분 읽기 중급 가이드

이 글의 핵심

Git 워크플로우 완벽 가이드입니다. 브랜치 전략, 커밋 컨벤션, PR 리뷰 등 실무 협업 방법을 상세히 설명합니다.

들어가며: Git은 협업 도구

”혼자 개발할 때는 괜찮은데, 팀에서는 충돌이 자주 나요”

Git은 단순한 버전 관리 도구가 아니라 팀 협업의 핵심입니다. 좋은 Git 워크플로우는 충돌을 줄이고 코드 품질을 높입니다.

이 글에서 다루는 것:

Git 브랜치 전략 (Git Flow, GitHub Flow, Trunk-Based)
커밋 컨벤션
PR(Pull Request) 작성 및 리뷰
충돌 해결
팀 규모별 권장 전략

1. Git 브랜치 전략

Git Flow

Git Flow는 Vincent Driessen이 제안한 브랜치 모델로, 대규모 프로젝트에 적합합니다.

브랜치 구조:

gitGraph
    commit
    branch develop
    checkout develop
    commit
    branch feature/login
    checkout feature/login
    commit
    commit
    checkout develop
    merge feature/login
    branch release/1.0
    checkout release/1.0
    commit
    checkout main
    merge release/1.0 tag: "v1.0"
    checkout develop
    merge release/1.0

브랜치 종류:

main: 프로덕션 배포 브랜치 (항상 안정)
develop: 개발 통합 브랜치
feature/: 기능 개발 브랜치 (feature/login, feature/payment)
release/: 릴리스 준비 브랜치 (release/1.0, release/2.0)
hotfix/: 긴급 수정 브랜치 (hotfix/security-patch)

워크플로우:

# 1. feature 브랜치 생성
git checkout develop
git checkout -b feature/login

# 2. 개발 및 커밋
git add .
git commit -m "feat: 로그인 UI 추가"
git commit -m "feat: 로그인 API 연동"

# 3. develop에 병합
git checkout develop
git merge feature/login
git branch -d feature/login

# 4. release 브랜치 생성
git checkout -b release/1.0

# 5. 버그 수정 및 버전 업데이트
git commit -m "chore: 버전 1.0.0으로 업데이트"

# 6. main에 병합 및 태그
git checkout main
git merge release/1.0
git tag -a v1.0.0 -m "Release 1.0.0"

# 7. develop에도 병합
git checkout develop
git merge release/1.0
git branch -d release/1.0

장점:

✅ 명확한 릴리스 관리
✅ 안정적인 main 브랜치
✅ 병렬 개발 가능

단점:

❌ 복잡한 브랜치 구조
❌ 느린 배포 주기
❌ 소규모 팀에는 과함

GitHub Flow

GitHub Flow는 단순하고 빠른 배포에 적합합니다.

브랜치 구조:

gitGraph
    commit
    branch feature/login
    checkout feature/login
    commit
    commit
    checkout main
    merge feature/login tag: "deploy"
    branch feature/payment
    checkout feature/payment
    commit
    checkout main
    merge feature/payment tag: "deploy"

워크플로우:

# 1. feature 브랜치 생성
git checkout -b feature/login

# 2. 개발 및 커밋
git commit -m "feat: 로그인 기능 추가"

# 3. PR 생성
git push origin feature/login
# GitHub에서 PR 생성

# 4. 리뷰 및 병합
# PR 승인 후 main에 병합

# 5. 배포
# main 병합 시 자동 배포 (CI/CD)

장점:

✅ 단순한 구조
✅ 빠른 배포
✅ CI/CD 친화적

단점:

❌ 릴리스 관리 약함
❌ 롤백 어려움

Trunk-Based Development

Trunk-Based Development는 main 브랜치에 직접 커밋하거나, 매우 짧은 수명의 브랜치만 사용합니다.

워크플로우:

# 1. main에서 작업
git checkout main
git pull

# 2. 짧은 브랜치 (1-2일)
git checkout -b fix-bug

# 3. 빠른 병합
git commit -m "fix: 버그 수정"
git push origin fix-bug
# PR 생성 및 즉시 병합 (몇 시간 내)

# 4. 브랜치 삭제
git branch -d fix-bug

장점:

✅ 매우 빠른 통합
✅ 병합 충돌 최소화
✅ 지속적 배포 (CD)

단점:

❌ 높은 테스트 커버리지 필요
❌ 자동화 필수
❌ 팀 숙련도 요구

브랜치 전략 비교

특징	Git Flow	GitHub Flow	Trunk-Based
복잡도	높음	낮음	매우 낮음
배포 속도	느림	빠름	매우 빠름
릴리스 관리	우수	보통	약함
팀 크기	대규모	중소규모	소규모
학습 곡선	높음	낮음	중간

2. 커밋 컨벤션

Conventional Commits

형식:

<type>(<scope>): <subject>

<body>

<footer>

Type 종류:

feat: 새 기능
fix: 버그 수정
docs: 문서 변경
style: 코드 포맷팅 (기능 변경 없음)
refactor: 리팩토링
test: 테스트 추가/수정
chore: 빌드, 설정 변경

예제:

# 좋은 커밋 메시지
git commit -m "feat: 사용자 로그인 기능 추가"
git commit -m "fix: 회원가입 시 이메일 검증 버그 수정"
git commit -m "docs: README에 설치 가이드 추가"
git commit -m "refactor: 사용자 서비스 로직 개선"

# 나쁜 커밋 메시지
git commit -m "수정"  # 너무 모호
git commit -m "asdf"  # 의미 없음
git commit -m "bug fix"  # 어떤 버그?

상세 커밋 메시지:

git commit -m "feat: 사용자 로그인 기능 추가

- JWT 토큰 기반 인증 구현
- 로그인 API 엔드포인트 추가 (POST /api/auth/login)
- 로그인 UI 컴포넌트 작성
- 세션 관리 로직 추가

Closes #123"

커밋 크기

권장:

하나의 커밋은 하나의 논리적 변경
200-400줄 이내
빌드 가능한 상태 유지

예제:

# ❌ 나쁜 예: 너무 큰 커밋
git add .
git commit -m "로그인, 회원가입, 프로필, 설정 기능 추가"
# 1000줄 변경, 리뷰 어려움

# ✅ 좋은 예: 작은 커밋들
git commit -m "feat: 로그인 UI 추가"  # 100줄
git commit -m "feat: 로그인 API 연동"  # 50줄
git commit -m "test: 로그인 테스트 추가"  # 80줄

3. PR 작성 및 리뷰

PR 템플릿

## 변경 사항
- 로그인 기능 추가
- JWT 토큰 기반 인증 구현

## 테스트
- [ ] 로그인 성공 케이스
- [ ] 잘못된 비밀번호 케이스
- [ ] 존재하지 않는 사용자 케이스

## 스크린샷
(UI 변경 시 스크린샷 첨부)

## 관련 이슈
Closes #123

PR 크기

권장:

200-400줄 이내
리뷰 시간 30분 이내
하루 1-2개

예제:

# ❌ 나쁜 예: 거대한 PR
# 파일 50개, 2000줄 변경
# 리뷰 시간 3시간+

# ✅ 좋은 예: 작은 PR들
# PR 1: 로그인 UI (5파일, 200줄)
# PR 2: 로그인 API (3파일, 150줄)
# PR 3: 로그인 테스트 (2파일, 100줄)

코드 리뷰 체크리스트

기능:

요구사항 충족
엣지 케이스 처리
에러 처리

코드 품질:

가독성
중복 코드 없음
네이밍 명확

테스트:

테스트 코드 포함
테스트 통과
커버리지 유지

성능:

불필요한 연산 없음
메모리 누수 없음

보안:

입력 검증
SQL 인젝션 방지
XSS 방지

4. 충돌 해결

충돌이 발생하는 이유

gitGraph
    commit id: "A"
    branch feature
    checkout feature
    commit id: "B (파일 수정)"
    checkout main
    commit id: "C (같은 파일 수정)"
    checkout feature
    merge main id: "충돌!"

충돌 예제:

# main 브랜치
# file.txt
line 1
line 2 (main에서 수정)
line 3

# feature 브랜치
# file.txt
line 1
line 2 (feature에서 수정)
line 3

# 병합 시도
git merge feature

# 충돌 발생
<<<<<<< HEAD
line 2 (main에서 수정)
=======
line 2 (feature에서 수정)
>>>>>>> feature

충돌 해결 방법

1. 수동 해결:

# 1. 충돌 파일 확인
git status

# 2. 파일 열어서 수동 편집
# <<<<<<< HEAD
# =======
# >>>>>>> feature
# 위 마커 제거하고 원하는 내용으로 수정

# 3. 충돌 해결 표시
git add file.txt

# 4. 병합 완료
git commit

2. 도구 사용:

# VS Code, IntelliJ 등 IDE의 병합 도구 사용
# 또는 전용 도구
git mergetool

# 충돌 해결 후
git commit

충돌 예방 전략

1. 자주 pull 받기:

# 매일 아침 main 최신 상태로 업데이트
git checkout main
git pull
git checkout feature/my-work
git merge main  # 또는 git rebase main

2. 작은 PR:

변경 범위 최소화
빠른 병합

3. 파일 분리:

큰 파일을 작은 모듈로 분리
팀원마다 다른 파일 작업

5. 팀 규모별 전략

1-3명 팀

권장: GitHub Flow

# 단순한 워크플로우
git checkout -b feature/new-feature
git commit -m "feat: 새 기능"
git push origin feature/new-feature
# PR 생성 및 병합

특징:

빠른 배포
최소한의 규칙
직접 소통 가능

4-10명 팀

권장: GitHub Flow + 릴리스 브랜치

# feature 브랜치
git checkout -b feature/login

# PR 리뷰 필수
# 2명 이상 승인 필요

# 릴리스 브랜치 (선택)
git checkout -b release/1.0
# 버그 수정만
git checkout main
git merge release/1.0
git tag v1.0.0

특징:

코드 리뷰 강화
릴리스 관리
CI/CD 자동화

10명 이상 팀

권장: Git Flow

# 명확한 브랜치 전략
main (프로덕션)
├── develop (개발)
│   ├── feature/login
│   ├── feature/payment
│   └── feature/admin
├── release/1.0
└── hotfix/security

특징:

엄격한 릴리스 프로세스
다중 버전 지원
롤백 전략 명확

6. 정리

핵심 요약

브랜치 전략:

Git Flow: 대규모, 명확한 릴리스
GitHub Flow: 소규모, 빠른 배포
Trunk-Based: 지속적 통합

커밋 컨벤션:

Conventional Commits 사용
작은 단위로 자주 커밋
의미 있는 메시지

PR 작성:

200-400줄 이내
명확한 설명
테스트 포함

충돌 해결:

자주 pull 받기
작은 PR로 충돌 최소화
도구 활용

팀 규모별 권장 전략

팀 크기	전략	특징
1-3명	GitHub Flow	단순, 빠름
4-10명	GitHub Flow + 릴리스	균형
10명+	Git Flow	엄격, 안정

다음 단계

Git 워크플로우를 CI/CD와 연결하여 자동화하세요:

GitHub Actions CI/CD
Node.js CI/CD 파이프라인

관련 주제:

Git 고급 기법
코드 리뷰 가이드
CI/CD 전략

추가 학습 자료

공식 문서:

이 글의 핵심

들어가며: Git은 협업 도구

”혼자 개발할 때는 괜찮은데, 팀에서는 충돌이 자주 나요”

목차

1. Git 브랜치 전략

Git Flow

GitHub Flow

Trunk-Based Development

브랜치 전략 비교

2. 커밋 컨벤션

Conventional Commits

커밋 크기

3. PR 작성 및 리뷰

PR 템플릿

PR 크기

코드 리뷰 체크리스트

4. 충돌 해결

충돌이 발생하는 이유

충돌 해결 방법

충돌 예방 전략

5. 팀 규모별 전략

1-3명 팀

4-10명 팀

10명 이상 팀

6. 정리

핵심 요약

팀 규모별 권장 전략

다음 단계

추가 학습 자료