Git 워크플로우 가이드: 팀을 위한 브랜칭 전략

· 12분 읽기

📑 목차

Git은 전 세계 개발팀의 95% 이상이 사용하는 버전 관리의 확실한 강자입니다. 하지만 Git 명령어를 아는 것은 절반의 성공일 뿐입니다. 진짜 도전은 팀에 맞는 브랜칭 전략을 선택하고 일관되게 따르는 것입니다.

좋은 Git 워크플로우는 병합 충돌을 방지하고, 병렬 개발을 가능하게 하며, 코드 품질을 유지하고, 릴리스를 예측 가능하게 만듭니다. 워크플로우가 없다면 혼란, 빌드 실패, 좌절한 개발자들을 마주하게 될 것입니다.

Git 워크플로우가 중요한 이유

이런 상황을 상상해보세요: 금요일 오후, 팀이 방금 중요한 버그 수정을 프로덕션에 푸시했습니다. 그런데 잠깐 — 다른 누군가가 동시에 테스트되지 않은 기능을 main에 직접 병합했습니다. 이제 프로덕션이 망가졌고, 어떤 커밋이 문제를 일으켰는지 아무도 모르며, 주말 계획이 망가졌습니다.

이런 시나리오는 정의된 Git 워크플로우가 없는 팀에서 발생합니다. 다음과 같은 문제가 생깁니다:

잘 정의된 Git 워크플로우는 언제 브랜치를 만들고, 어떻게 병합하며, 누가 변경사항을 승인하는지에 대한 명확한 규칙을 수립합니다. 코드가 개발에서 프로덕션으로 어떻게 이동하는지에 대한 팀 전체의 공통된 이해를 만듭니다.

프로 팁: 최고의 워크플로우는 팀이 실제로 따르는 것입니다. 간단하게 시작하고 필요할 때만 복잡성을 추가하세요. 모두가 이해하는 기본 워크플로우가 아무도 따르지 않는 정교한 워크플로우보다 낫습니다.

피처 브랜치 워크플로우

피처 브랜치 워크플로우는 가장 널리 채택된 Git 워크플로우이며, 그럴 만한 이유가 있습니다. 간단하고 유연하며 모든 규모의 팀에 적합합니다. 핵심 원칙: 모든 새로운 기능이나 버그 수정은 main에서 생성된 자체 브랜치를 갖습니다.

개발자들은 피처 브랜치에서 독립적으로 작업한 다음, 코드 리뷰 후 main으로 다시 병합하기 위해 풀 리퀘스트를 생성합니다. 이렇게 하면 main이 항상 안정적이고 배포 가능한 상태로 유지됩니다.

작동 방식

새로운 기능을 추가하는 일반적인 흐름은 다음과 같습니다:

# main에서 시작하고 최신 변경사항 가져오기
git checkout main
git pull origin main

# 새 피처 브랜치 생성
git checkout -b feature/user-authentication

# 변경사항 만들고 커밋
git add .
git commit -m "feat: add login form validation"

# 원격에 푸시
git push origin feature/user-authentication

# 코드 리뷰를 위해 GitHub/GitLab에서 PR 생성
# 승인 후 main에 병합
# 피처 브랜치 삭제

브랜치 명명 규칙

일관된 명명은 각 브랜치가 무엇을 하는지 쉽게 이해할 수 있게 합니다. 일반적인 접두사는 다음과 같습니다:

피처 브랜치 워크플로우를 사용할 때

이 워크플로우는 다음과 같은 경우에 빛을 발합니다:

잠재적 함정

다음과 같은 일반적인 문제를 주의하세요:

빠른 팁: 피처 브랜치를 단기간(이상적으로 3일 미만)으로 유지하세요. 기능이 더 오래 걸린다면, 피처 플래그 뒤에서 점진적으로 병합할 수 있는 더 작은 조각으로 나누세요.

GitFlow 워크플로우

GitFlow는 예정된 릴리스가 있는 프로젝트를 위해 설계된 더 구조화된 워크플로우입니다. 개발과 릴리스 준비의 다양한 단계를 관리하기 위해 여러 장기 브랜치를 사용합니다.

2010년 Vincent Driessen이 만든 GitFlow는 정기적인 릴리스 일정(월별, 분기별 등)으로 소프트웨어를 출시하는 팀에게 인기를 얻었습니다. 개발, 릴리스 준비, 프로덕션 코드 간의 명확한 분리를 제공합니다.

브랜치 구조

GitFlow는 다섯 가지 유형의 브랜치를 사용합니다:

완전한 GitFlow 사이클

코드가 GitFlow를 통해 흐르는 방식은 다음과 같습니다:

# GitFlow 초기화 (일회성 설정)
git flow init

# 새 기능 시작
git flow feature start user-profile
# 기능 작업...
git flow feature finish user-profile
# 자동으로 develop에 병합

# develop이 준비되면 릴리스 시작
git flow release start 1.2.0
# 버그 수정과 버전 업데이트만
git flow release finish 1.2.0
# main과 develop에 병합, 태그 생성

# 긴급 핫픽스
git flow hotfix start security-patch
# 문제 수정...
git flow hotfix finish security-patch
# main과 develop에 병합

GitFlow가 적합한 경우

GitFlow는 다음과 같은 경우에 잘 작동합니다:

GitFlow가 인기를 잃은 이유

많은 현대 팀들이 GitFlow에서 벗어난 이유는 다음과 같습니다:

GitFlow의 창시자인 Vincent Driessen조차도 이제 지속적으로 배포하는 대부분의 웹 애플리케이션에는 더 간단한 워크플로우를 권장합니다.

트렁크 기반 개발

트렁크 기반 개발(TBD)은 Google, Facebook, Netflix의 고성능 엔지니어링 팀이 사용하는 워크플로우입니다. GitFlow의 반대입니다 — 장기 브랜치 대신 개발자들이 main("트렁크")에 직접 커밋하거나 매우 단기적인 피처 브랜치를 사용합니다.

핵심 원칙: 대규모 병합의 고통을 피하기 위해 코드를 자주(하루에 여러 번) 통합합니다.

트렁크 기반 개발 작동 방식

TBD에는 두 가지 변형이 있습니다:

main에 직접 커밋:

# 최신 변경사항 가져오기
git pull origin main

# 작은 변경사항 만들기
git add .
git commit -m "feat: add email validation"

# main에 직접 푸시
git push origin main

단기 피처 브랜치 (대부분의 팀에 권장):

# 작은 변경을 위한 브랜치 생성
git checkout -b add-email-validation

# 변경사항 만들고 커밋
git add .
git commit -m "feat: add email validation"

# 푸시하고 PR 생성
git push origin add-email-validation

# 24시간 내에 병합, 브랜치 삭제

피처 플래그의 역할

트렁크 기반 개발은 불완전한 기능을 사용자로부터 숨기기 위해 피처 플래그(피처 토글이라고도 함)에 크게 의존합니다. 이를 통해 프로덕션 준비가 되기 전에 코드를 main에 병합할 수 있습니다.

// 피처 플래그 예시
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckoutFlow />;
}
return <OldCheckoutFlow />;

피처 플래그를 사용하면 다음을 할 수 있습니다:

성공적인 TBD를 위한 요구사항

트렁크 기반 개발은 강력한 엔지니어링 관행이 필요합니다:

트렁크 기반 개발의 이점

제대로 수행하면 TBD는 상당한 이점을 제공합니다:

프로 팁: 팀이 CI/CD에 익숙하지 않다면 트렁크 기반 개발로 바로 뛰어들지 마세요. 먼저 테스트 인프라와 배포 자동화를 구축한 다음, 점진적으로 피처 브랜치 수명을 단축하세요.

팀에 적합한 워크플로우 선택하기

만능 답은 없습니다. 올바른 워크플로우는 팀 규모, 릴리스 주기, 엔지니어링 성숙도에 따라 다릅니다. 결정하는 방법은 다음과 같습니다:

워크플로우 최적 대상 팀 규모 릴리스 주기
피처 브랜치 웹 앱, SaaS 제품, 대부분의 현대 팀 모든 규모 지속적 또는 주간
GitFlow 데스크톱/모바일 앱, 버전 릴리스 중간에서 대규모 월간 또는 분기별
트렁크 기반 강력한 CI/CD를 갖춘 고속 팀 모든 규모 (규율 필요) 하루에 여러 번

의사결정 프레임워크

다음 질문들을 스스로에게 물어보세요:

1. 프로덕션에 얼마나 자주 배포하나요?

2. CI/CD 파이프라인이 얼마나 성숙했나요?