[이제와서 시작하는 GitHub 마스터하기 - 기초편 #13] 브랜치 전략: 효율적인 협업 워크플로우

학습 목표

이 장을 마치면 다음을 할 수 있습니다:

• ✅ 주요 브랜치 전략을 이해할 수 있습니다
• ✅ 프로젝트에 맞는 전략을 선택할 수 있습니다
• ✅ Git Flow, GitHub Flow를 활용할 수 있습니다
• ✅ 효율적인 협업 워크플로우를 구축할 수 있습니다

지난 편 복습

기초편 #12에서는 Merge와 Rebase를 배웠습니다:

• Merge와 Rebase의 차이점 이해
• 브랜치 병합(Merge) 방법
• Rebase로 깔끔한 히스토리 만들기
• 충돌(Conflict) 해결 방법

브랜치 전략이란?

개념

브랜치 전략은 팀이 효율적으로 협업하기 위한 브랜치 사용 규칙입니다.

필요한 이유:

• 🎯 일관된 개발 프로세스
• 🔒 안정적인 배포
• 👥 명확한 협업 규칙
• 🚀 효율적인 릴리스

주요 브랜치 전략

1. Git Flow

가장 전통적이고 체계적인 전략

gitGraph
    commit tag: "v1.0"
    branch develop
    checkout develop
    commit
    branch feature
    checkout feature
    commit
    commit
    checkout develop
    merge feature
    branch release
    checkout release
    commit
    checkout main
    merge release tag: "v1.1"
    checkout develop
    merge release

브랜치 종류

영구 브랜치:

• main (또는 master): 배포된 프로덕션 코드
• develop: 다음 릴리스를 위한 개발 코드

임시 브랜치:

• feature/*: 새 기능 개발
• release/*: 릴리스 준비
• hotfix/*: 긴급 버그 수정

워크플로우

# 1. 기능 개발
git checkout develop
git checkout -b feature/login

# 작업 후
git checkout develop
git merge feature/login
git branch -d feature/login

# 2. 릴리스 준비
git checkout develop
git checkout -b release/v1.1.0

# 버그 수정 후
git checkout main
git merge release/v1.1.0
git tag v1.1.0

git checkout develop
git merge release/v1.1.0
git branch -d release/v1.1.0

# 3. 긴급 수정
git checkout main
git checkout -b hotfix/critical-bug

# 수정 후
git checkout main
git merge hotfix/critical-bug
git tag v1.1.1

git checkout develop
git merge hotfix/critical-bug
git branch -d hotfix/critical-bug

장단점

장점 ✅:

• 명확한 구조
• 안정적인 릴리스
• 대규모 프로젝트 적합

단점 ❌:

• 복잡함
• 브랜치 관리 부담
• CI/CD에는 과도할 수 있음

적합한 프로젝트:

• 정기적인 릴리스 주기
• 여러 버전 동시 지원
• 대규모 팀

2. GitHub Flow

간단하고 빠른 배포 중심 전략

gitGraph
    commit
    branch feature
    checkout feature
    commit
    commit
    checkout main
    merge feature
    commit tag: "deploy"
    branch hotfix
    checkout hotfix
    commit
    checkout main
    merge hotfix
    commit tag: "deploy"

워크플로우

# 1. 브랜치 생성
git checkout main
git pull origin main
git checkout -b feature/new-feature

# 2. 작업 및 커밋
git add .
git commit -m "feat: add new feature"

# 3. 푸시
git push origin feature/new-feature

# 4. Pull Request 생성 (GitHub에서)

# 5. 코드 리뷰

# 6. 승인 후 병합 및 배포

# 7. 브랜치 삭제
git branch -d feature/new-feature

규칙

1. main 브랜치는 항상 배포 가능
2. 새 작업은 main에서 브랜치 생성
3. 정기적으로 푸시
4. Pull Request로 병합
5. 승인 후 즉시 배포

장단점

장점 ✅:

• 단순함
• 빠른 배포
• CI/CD 친화적

단점 ❌:

• 릴리스 관리 어려움
• 여러 버전 지원 곤란

적합한 프로젝트:

• 웹 서비스
• 지속적 배포 (CD)
• 소규모~중규모 팀

3. GitLab Flow

GitHub Flow + 환경별 브랜치

gitGraph
    commit
    branch production
    checkout main
    commit
    commit
    checkout production
    merge main tag: "v1.1"
    checkout main
    commit
    commit
    checkout production
    merge main tag: "v1.2"

환경별 브랜치

• main: 개발 환경
• pre-production: 스테이징 환경
• production: 프로덕션 환경

워크플로우

# 1. 기능 개발
git checkout main
git checkout -b feature/new-feature

# 2. PR 병합
# main에 병합

# 3. 스테이징 배포
git checkout pre-production
git merge main
# 자동 배포 to staging

# 4. 프로덕션 배포
git checkout production
git merge pre-production
# 자동 배포 to production

4. Trunk-Based Development

main 브랜치 중심, 짧은 수명 브랜치

gitGraph
    commit
    branch feature-1
    checkout feature-1
    commit
    checkout main
    merge feature-1
    branch feature-2
    checkout feature-2
    commit
    checkout main
    merge feature-2
    commit

특징

• 짧은 수명 브랜치 (1-2일)
• 자주 병합
• Feature Flag 사용
• 높은 테스트 커버리지 필수

프로젝트별 전략 선택

선택 가이드

프로젝트 유형	추천 전략	이유
웹 서비스	GitHub Flow	빠른 배포, 단순함
모바일 앱	Git Flow	앱스토어 심사, 버전 관리
라이브러리	Git Flow	여러 버전 지원
스타트업	GitHub Flow	빠른 반복, 민첩성
엔터프라이즈	GitLab Flow	환경별 배포
오픈소스	GitHub Flow	기여자 친화적

팀 규모별 전략

소규모 (1-5명):

• GitHub Flow
• 간단한 규칙
• 빠른 의사결정

중규모 (6-20명):

• GitHub Flow 또는 GitLab Flow
• PR 리뷰 필수
• 자동화 도입

대규모 (21명 이상):

• Git Flow 또는 GitLab Flow
• 명확한 프로세스
• 팀별 브랜치 전략

실전 팁

브랜치 네이밍

# 기능
feature/user-authentication
feature/payment-integration

# 버그 수정
fix/login-error
bugfix/memory-leak

# 핫픽스
hotfix/security-patch
hotfix/critical-bug

# 릴리스
release/v1.2.0
release/2024-01-15

# 문서
docs/api-guide
docs/readme-update

PR(Pull Request) 규칙

제목:
  - "feat: 간결한 설명 (50자 이내)"
  - "fix: 버그 설명"

본문:
  - 변경 이유
  - 해결 방법
  - 테스트 방법

리뷰어:
  - 최소 1명 승인
  - CI 통과 필수

보호 규칙 설정

# GitHub에서 설정
Settings → Branches → Branch protection rules

- main 브랜치 보호
- PR 필수
- 리뷰 승인 필요 (1-2명)
- CI 통과 필수
- 강제 푸시 금지

자주 묻는 질문 (FAQ)

Q1. 어떤 전략이 가장 좋나요?

A: 프로젝트에 따라 다릅니다:

• 빠른 배포: GitHub Flow
• 안정성 중시: Git Flow
• 환경별 관리: GitLab Flow

Q2. 전략을 바꿀 수 있나요?

A: 네, 가능합니다. 팀 상황에 맞게 조정하세요.

# Git Flow → GitHub Flow 전환
1. develop 브랜치를 main에 병합
2. 앞으로 main만 사용
3. PR로 병합

Q3. 개인 프로젝트에도 필요한가요?

A: 간단한 전략 권장:

• main + feature 브랜치만 사용
• PR은 선택사항
• 일관성 유지가 핵심

Q4. hotfix는 언제 사용하나요?

A: 긴급한 프로덕션 버그만:

• 서비스 중단
• 보안 취약점
• 데이터 손실 위험

일반 버그는 feature/fix 브랜치 사용

실습 과제

과제 1: GitHub Flow 연습

1. main 브랜치에서 시작
2. feature 브랜치 생성 및 작업
3. 푸시 및 PR 생성
4. 병합 및 배포

과제 2: Git Flow 시뮬레이션

1. develop 브랜치 생성
2. feature 브랜치에서 기능 개발
3. develop에 병합
4. release 브랜치 생성
5. main에 병합 및 태깅

과제 3: 팀 규칙 만들기

프로젝트에 맞는 브랜치 전략 문서 작성:

• 브랜치 종류
• 네이밍 규칙
• PR 프로세스
• 배포 절차

마무리

축하합니다! 브랜치 전략을 마스터했습니다.

핵심 요약:

• ✅ Git Flow: 체계적, 대규모 프로젝트
• ✅ GitHub Flow: 단순, 빠른 배포
• ✅ GitLab Flow: 환경별 관리
• ✅ 선택: 프로젝트 특성에 맞게

다음 편에서는 Fork와 Clone을 배워보겠습니다!

📚 GitHub 마스터하기 시리즈

🌱 기초편 (입문자)

1. GitHub 소개와 계정 만들기
2. 프로필 꾸미기와 포트폴리오
3. 보안 설정과 인증
4. Repository 이해하기
5. README 작성법
6. .gitignore와 라이선스
7. 첫 커밋과 관리
8. git add와 commit
9. git push와 pull
10. 실전 워크플로우
11. Branch 기본
12. Merge와 Rebase
13. 브랜치 전략 👉 현재 글
14. Fork와 Clone
15. Pull Request

💼 실전편 (중급자)

1. Issues 활용법
2. Projects와 칸반보드
3. 코드 리뷰 실전
4. Discussions 활용
5. 팀 협업 전략
6. GitHub Pages 블로그

🚀 고급편 (전문가)

1. GitHub Actions 입문
2. Actions 고급 활용
3. Webhooks와 API
4. GitHub Apps 개발
5. 보안 기능 활용
6. Packages 레지스트리
7. Codespaces 클라우드 개발
8. GitHub CLI 마스터
9. Insights와 Analytics

🏆 심화편 (전문가+)

1. Submodules와 Subtree
2. Git Internals 이해
3. 브랜칭과 릴리스 전략
4. GraphQL API 활용
5. GitHub Copilot 마스터