[250213 TIL] TBD vs Github Flow(개념정리)

📌 Trunk-Based Development vs GitHub Flow 차이점

둘 다 가벼운 브랜치 전략으로, 빠른 배포를 목표로 합니다. 하지만 몇 가지 중요한 차이가 있습니다.

---

🚀 1. Trunk-Based Development (TBD)

✅ 핵심 개념:

• main 브랜치(=Trunk)에서 직접 개발하고,
• 짧은-lived feature 브랜치만 사용하며,
• 하루에도 여러 번 main에 머지하는 방식.

✅ 특징:

• 브랜치는 짧게 유지 → 몇 시간 또는 하루 이내 병합
• Long-lived feature 브랜치 없음 → develop 브랜치 X
• CI/CD 필수 → main에 병합 시 항상 배포 가능 상태 유지

✅ 워크플로우:

1. main에서 직접 개발하거나 짧은-lived 브랜치 생성
2. 빠르게 개발 후 main에 머지
3. CI/CD가 main의 상태를 항상 배포 가능하도록 유지

✅ 장점:

• 빠른 배포 & 지속적 통합 가능
• 충돌 관리가 쉽고 코드 병합이 간단
• 롤백이 빠름 (feature flag와 함께 사용)

✅ 단점:

• 즉시 배포 가능한 코드 품질 유지 필요
• 팀원 간 충돌 가능성이 높음 → 코드 리뷰 & CI/CD 필수
• Feature toggle(플래그) 필요 → 미완성 기능을 숨기려면 설정 필요

✅ 사용 사례:

• Google, Meta, Netflix 등 배포 속도가 중요한 대규모 서비스
• DevOps, CI/CD 환경이 잘 갖춰진 조직

---

🚀 2. GitHub Flow

✅ 핵심 개념:

• main 브랜치에서 배포 가능한 상태 유지,
• 모든 변경 사항은 feature 브랜치에서 개발 후
• Pull Request를 통해 main에 머지하는 방식.

✅ 특징:

• main 브랜치는 항상 배포 가능해야 함
• Feature 브랜치를 생성하고 PR(Pull Request)로 머지
• CI/CD를 통해 main 브랜치가 업데이트되면 자동 배포

✅ 워크플로우:

1. main에서 feature 브랜치 생성
2. 브랜치에서 개발 진행 후 PR 작성
3. 코드 리뷰 후 main에 머지
4. CI/CD를 통해 배포

✅ 장점:

• 단순한 브랜치 전략 → 배우기 쉽고 관리 용이
• 배포 자동화와 잘 맞음 → PR 병합 후 자동 배포
• GitHub과 연계 → GitHub Actions, CI/CD와 쉽게 통합 가능

✅ 단점:

• 긴-lived 브랜치가 생길 가능성 → PR 리뷰 대기 시 지연 발생
• 코드 충돌 가능성 → 브랜치가 길어지면 충돌 위험 증가
• Feature toggle 필요할 수 있음 → 큰 기능 추가 시 미완성 코드 방지 필요

✅ 사용 사례:

• 스타트업, 소규모 프로젝트
• GitHub Actions 기반 CI/CD가 있는 환경

---

🔍 차이점 정리

	Trunk-Based Development	GitHub Flow
브랜치 구조	main에서 직접 개발, 짧은-lived 브랜치 사용	main에서 feature 브랜치 생성 후 PR로 병합
병합 방식	직접 main에 머지	PR을 통한 리뷰 후 main에 머지
배포 전략	main은 항상 배포 가능 상태, 즉시 병합 & 배포	PR 병합 후 CI/CD를 통해 자동 배포
코드 리뷰	코드 리뷰 없이 바로 머지 가능 (CI 테스트 필수)	PR을 통한 코드 리뷰 필수
Feature 브랜치	거의 없음 (있어도 매우 짧게)	Feature 브랜치를 적극적으로 활용
CI/CD 필요 여부	필수	필수
적합한 팀 규모	대규모 팀, DevOps 조직	소규모 팀, 스타트업, GitHub 중심 개발

---

🎯 결론

• TBD → 빠른 배포가 중요한 대기업, DevOps 조직에 적합
• GitHub Flow → 소규모 팀, GitHub 기반 프로젝트에 적합

둘 다 배포 자동화와 CI/CD가 필수이지만,
GitHub Flow는 PR 중심의 협업을 중요시하고,
Trunk-Based는 직접 main에서 작업하는 점이 가장 큰 차이입니다.