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

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

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

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

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

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

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

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

이 글의 핵심

Git 브랜치 전략, 커밋 컨벤션, PR 리뷰, 충돌 해결 등 실무 Git 워크플로우를 상세히 설명합니다. Git Flow, GitHub Flow, Trunk-Based Development를 비교하고 팀 규모별 권장 전략을 제시합니다.

들어가며: Git은 협업 도구

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

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

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

실무에서 마주한 현실

개발을 배울 때는 모든 게 깔끔하고 이론적입니다. 하지만 실무는 다릅니다. 레거시 코드와 씨름하고, 급한 일정에 쫓기고, 예상치 못한 버그와 마주합니다. 이 글에서 다루는 내용도 처음엔 이론으로 배웠지만, 실제 프로젝트에 적용하면서 “아, 이래서 이렇게 설계하는구나” 하고 깨달은 것들입니다. 특히 기억에 남는 건 첫 프로젝트에서 겪은 시행착오입니다. 책에서 배운 대로 했는데 왜 안 되는지 몰라 며칠을 헤맸죠. 결국 선배 개발자의 코드 리뷰를 통해 문제를 발견했고, 그 과정에서 많은 걸 배웠습니다. 이 글에서는 이론뿐 아니라 실전에서 마주칠 수 있는 함정들과 해결 방법을 함께 다루겠습니다.

1. Git 브랜치 전략

Git Flow

Git Flow는 Vincent Driessen이 제안한 브랜치 모델로, 대규모 프로젝트에 적합합니다. 브랜치 구조: 다음은 mermaid를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

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) 워크플로우: 다음은 bash를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 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는 단순하고 빠른 배포에 적합합니다. 브랜치 구조: 아래 코드는 mermaid를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

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"

워크플로우: 다음은 bash를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 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 브랜치에 직접 커밋하거나, 매우 짧은 수명의 브랜치만 사용합니다. 워크플로우: 아래 코드는 bash를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 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: 빌드, 설정 변경 예제: 아래 코드는 bash를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 좋은 커밋 메시지
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"  # 어떤 버그?

상세 커밋 메시지: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

git commit -m "feat: 사용자 로그인 기능 추가
- JWT 토큰 기반 인증 구현
- 로그인 API 엔드포인트 추가 (POST /api/auth/login)
- 로그인 UI 컴포넌트 작성
- 세션 관리 로직 추가
Closes #123"

커밋 크기

권장:

하나의 커밋은 하나의 논리적 변경
200-400줄 이내
빌드 가능한 상태 유지 예제: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# ❌ 나쁜 예: 너무 큰 커밋
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 템플릿

아래 코드는 markdown를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

## 변경 사항

- 로그인 기능 추가
- JWT 토큰 기반 인증 구현
## 테스트

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

(UI 변경 시 스크린샷 첨부)
## 관련 이슈

Closes #123

PR 크기

권장:

200-400줄 이내
리뷰 시간 30분 이내
하루 1-2개 예제: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# ❌ 나쁜 예: 거대한 PR
# 파일 50개, 2000줄 변경
# 리뷰 시간 3시간+
# ✅ 좋은 예: 작은 PR들
# PR 1: 로그인 UI (5파일, 200줄)
# PR 2: 로그인 API (3파일, 150줄)
# PR 3: 로그인 테스트 (2파일, 100줄)

코드 리뷰 체크리스트

기능:

4. 충돌 해결

충돌이 발생하는 이유

아래 코드는 mermaid를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

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

충돌 예제: 다음은 bash를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 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. 수동 해결: 아래 코드는 bash를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 1. 충돌 파일 확인
git status
# 2. 파일 열어서 수동 편집
# <<<<<<< HEAD
# =======
# >>>>>>> feature
# 위 마커 제거하고 원하는 내용으로 수정
# 3. 충돌 해결 표시
git add file.txt
# 4. 병합 완료
git commit

2. 도구 사용: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# VS Code, IntelliJ 등 IDE의 병합 도구 사용
# 또는 전용 도구
git mergetool
# 충돌 해결 후
git commit

충돌 예방 전략

1. 자주 pull 받기: 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# 매일 아침 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 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

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

특징:

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

4-10명 팀

권장: GitHub Flow + 릴리스 브랜치 아래 코드는 bash를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.

# 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 아래 코드는 bash를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.

# 명확한 브랜치 전략
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와 연결하여 자동화하세요:

추가 학습 자료

공식 문서: