협업 워크플로

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• GitHub Flow와 Git Flow의 차이를 설명하고 상황에 맞게 선택할 수 있습니다.
• 오픈소스 프로젝트 기여를 위한 Fork & PR 워크플로를 이해합니다.
• GitHub에서 브랜치 보호 규칙을 설정해 main 직접 push를 차단할 수 있습니다.
• 팀 협업에서 충돌을 최소화하는 실천 방법을 알고 있습니다.

🌊 GitHub Flow — 단순하고 빠른 전략

이 섹션에서는 GitHub 자체에서 사용하며 스타트업·SaaS 팀에 널리 채택된 GitHub Flow를 살펴보겠습니다.

GitHub Flow는 GitHub 사에서 직접 개발하고 사용하는 브랜치 전략입니다. 규칙이 단순하고, 지속적 배포(Continuous Deployment)에 최적화되어 있습니다.

GitHub Flow의 원칙은 단 6가지입니다.

1. main 브랜치는 항상 배포 가능한 상태로 유지합니다.
2. 새 작업은 반드시 기능 브랜치에서 시작합니다.
3. 기능 브랜치 이름은 작업 내용을 명확히 설명합니다 (feature/user-auth).
4. 진행 중에도 원격 브랜치에 자주 push합니다 (백업 + 진행 상황 공유).
5. 피드백이나 도움이 필요할 때, 또는 완성됐을 때 Pull Request를 생성합니다.
6. PR이 승인되면 즉시 main에 병합·배포합니다.

# GitHub Flow 실전 흐름
git switch main
git pull                              # 최신 main 받기
git switch -c feature/shopping-cart   # 기능 브랜치
# ... 작업 ...
git add . && git commit -m "feat: 장바구니 추가 기능"
git push -u origin feature/shopping-cart  # 원격에 올리기
# GitHub에서 PR 생성 → 리뷰 → Approve → main에 merge → 배포

GitHub Flow는 팀 규모가 작거나, 자주 배포하는 SaaS 제품에 이상적입니다. 복잡한 규칙이 없어 진입 장벽이 낮고, PR 기반 협업이 자연스럽게 이루어집니다.

🔀 Git Flow — 릴리즈 주기가 있는 팀을 위한 전략

이 섹션에서는 Vincent Driessen이 제안하고 대기업·앱 스토어 배포 팀에서 사용하는 Git Flow를 살펴보겠습니다.

Git Flow는 GitHub Flow보다 복잡하지만, 버전을 명확히 관리하고 릴리즈 주기가 있는 팀(예: 모바일 앱, 기업 소프트웨어)에 적합합니다.

Git Flow에서 사용하는 브랜치 역할입니다.

브랜치	역할	특징
main	프로덕션 릴리즈	태그된 버전만 존재. 직접 커밋 금지
develop	다음 릴리즈 개발	기능들이 모이는 통합 브랜치
feature/*	개별 기능 개발	develop에서 분기, develop으로 병합
release/*	릴리즈 준비	버그 수정만, main+develop 양쪽에 병합
hotfix/*	프로덕션 긴급 수정	main에서 분기, main+develop 양쪽에 병합

# Git Flow 브랜치 흐름 예시

# 기능 개발
git switch develop
git switch -c feature/user-profile
# ... 개발 ...
git switch develop && git merge --no-ff feature/user-profile

# 릴리즈 준비
git switch -c release/v1.2.0
# 버그 수정만 진행
git switch main && git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "버전 1.2.0 릴리즈"
git switch develop && git merge --no-ff release/v1.2.0

# 긴급 패치
git switch main
git switch -c hotfix/payment-error
# 수정 후
git switch main && git merge --no-ff hotfix/payment-error
git switch develop && git merge --no-ff hotfix/payment-error

Git Flow는 강력하지만 복잡합니다. 소규모 팀이나 지속 배포 서비스에는 오히려 과도할 수 있습니다. 팀 규모와 배포 주기를 고려해 선택하세요.

🍴 Fork & PR — 오픈소스 기여 워크플로

이 섹션에서는 외부 개발자가 다른 사람의 저장소에 기여하는 Fork 방식의 워크플로를 살펴보겠습니다.

오픈소스 프로젝트(React, Vue, Python 등)에 기여하거나, 쓰기 권한이 없는 저장소에 수정을 제안할 때는 Fork를 사용합니다.

Fork는 다른 사람의 GitHub 저장소를 내 GitHub 계정으로 복사하는 것입니다. 내 저장소가 되므로 자유롭게 수정할 수 있습니다.

# Fork & PR 워크플로

# 1. GitHub 웹에서 원본 저장소의 "Fork" 버튼 클릭
#    → 내 GitHub 계정에 복사본 생성

# 2. 내 Fork를 로컬에 클론
git clone git@github.com:my-username/original-project.git
cd original-project

# 3. 원본 저장소를 upstream으로 등록
git remote add upstream git@github.com:original-author/original-project.git
git remote -v
# origin   git@github.com:my-username/original-project.git (내 fork)
# upstream git@github.com:original-author/original-project.git (원본)

# 4. 기능 브랜치에서 수정 작업
git switch -c fix/typo-in-readme
# ... 수정 ...
git commit -m "fix: README 오타 수정"

# 5. 내 Fork에 push
git push -u origin fix/typo-in-readme

# 6. GitHub 웹에서 원본 저장소로 PR 생성
#    (base: original-author/original-project:main ← head: my-username/original-project:fix/...)

# 7. 원본 저장소에 새 내용이 생기면 내 Fork에 동기화
git fetch upstream
git switch main
git merge upstream/main
git push origin main

🔒 브랜치 보호 규칙 — main 직접 push 차단

이 섹션에서는 GitHub의 브랜치 보호 규칙을 설정해 실수로 main에 직접 커밋하는 사고를 방지하는 방법을 살펴보겠습니다.

팀에서 실수로 main 브랜치에 직접 push하는 사고를 방지하기 위해 GitHub의 Branch protection rules를 설정합니다.

설정 위치: 저장소 Settings → Branches → Add rule

주요 설정 항목입니다.

• Require a pull request before merging: PR 없이 직접 push 금지
• Require approvals: 병합 전 최소 N명의 리뷰어 승인 필요 (예: 1명 이상)
• Require status checks to pass: CI(자동 테스트) 통과 후에만 병합 허용
• Require linear history: merge commit 없는 선형 히스토리 강제
• Include administrators: 관리자에게도 동일 규칙 적용

# 브랜치 보호가 설정된 경우 main 직접 push 시
git push origin main
# remote: error: GH006: Protected branch update failed for refs/heads/main.
# remote: error: Changes must be made through a pull request.
# → PR을 통해서만 main에 반영 가능

💡 충돌 최소화 팀 실천 방법

이 섹션에서는 팀 전체가 지키면 충돌 빈도와 복잡도를 크게 줄일 수 있는 실천 방법을 살펴보겠습니다.

• 브랜치를 짧게 유지: 하나의 PR은 하나의 목적, 1~3일 내 완료 목표. 오래 살아있는 브랜치일수록 병합이 어려워집니다.
• 자주 동기화: 기능 브랜치에서 작업하는 동안 매일 main을 당겨와 미리 충돌을 작은 단위로 해결합니다.
• 코딩 컨벤션 공유: 들여쓰기, 줄 끝 공백, 따옴표 스타일을 ESLint/Prettier/EditorConfig로 통일해 불필요한 포맷 차이를 없앱니다.
• 파일 단위 역할 분리: 팀원끼리 같은 파일을 동시에 수정하는 상황을 최소화하도록 작업 분배합니다.
• 스탠드업에서 작업 공유: 매일 팀 미팅에서 "오늘 어떤 파일을 건드릴 예정"인지 공유하면 겹침을 미리 파악할 수 있습니다.

📝 핵심 요약

13강에서 배운 내용을 정리해 보겠습니다.

전략	적합한 팀	핵심 특징
GitHub Flow	소규모, 지속 배포	main + 기능 브랜치만, 단순
Git Flow	릴리즈 주기 있는 팀	main/develop/feature/release/hotfix
Fork & PR	오픈소스 기여	원본 복사 후 PR로 제안

# Fork 후 upstream 동기화
git remote add upstream 원본URL
git fetch upstream
git merge upstream/main

다음 강인 14강 — 이슈와 프로젝트에서는 GitHub의 이슈(Issues) 기능으로 버그와 작업을 추적하고, 프로젝트(Projects) 보드로 팀 일정을 관리하는 방법을 배웁니다. 코드 외 협업 도구를 활용하면 개발 생산성이 크게 높아집니다!