Git과 브랜치 전략

Git 브랜치 전략 : Git Flow부터 Trunk-Based Development까지

팀의 규모, 배포 주기, 프로젝트의 성격에 따라 Git 브랜치 전략은 다양하게 구성됩니다. 잘 설계된 브랜치 전략은 코드 관리를 체계화하고 협업의 효율성을 극대화하는 핵심적인 역할을 합니다.

이 글에서는 주요 브랜치의 역할부터 Git Flow, GitHub Flow, 그리고 Trunk-based Development(TBD)와 같은 대표적인 브랜치 전략들을 살펴보고, 실제 오픈소스 프로젝트에서는 어떻게 활용되고 있는지 분석합니다.

1. 역할별 브랜치 종류와 개념

효과적인 브랜치 전략을 이해하기 위해, 먼저 각 브랜치가 어떤 목적을 가지고 사용되는지 알아야 합니다.

Dev (Development) 브랜치

• 새로운 기능 개발 및 버그 수정의 기반이 되는 중심 개발 브랜치입니다.
• 개발자들이 가장 활발하게 작업하며, 실험적이거나 아직 완성되지 않은 변경 사항을 포함할 수 있습니다.
• 일반적으로 안정성을 보장하지 않으며, 개발이 완료된 기능은 stage 브랜치로 병합됩니다.

Stage (Staging) 브랜치

• 배포 전 최종 테스트 환경을 위한 브랜치입니다.
• dev 브랜치에서 충분히 검증된 코드를 병합하여 통합 테스트와 품질 보증(QA)을 진행합니다.
• 모든 테스트를 통과한 코드는 prod 브랜치로 병합될 준비를 마칩니다.

Prod (Production) 브랜치

• 실제 사용자가 사용하는 프로덕션 환경의 코드를 관리하는 브랜치입니다.
• 이 브랜치의 코드는 반드시 안정적이고 즉시 배포 가능한 상태여야 합니다.
• 버전 태그(tag)를 통해 배포 이력을 관리하는 경우가 많으며, 긴급 수정이 필요할 때는 hotfix 브랜치가 이 브랜치에서 직접 분기됩니다.

Feature 브랜치

• 하나의 독립된 기능을 개발하기 위한 브랜치입니다.
• 보통 develop 브랜치에서 분기하여 작업을 시작하고, 개발이 완료되면 다시 develop 브랜치로 병합됩니다.
• 작명 규칙: feature/login-page, feature/api-integration 등 기능 이름을 포함하여 목적을 명확히 합니다.

Release 브랜치

• 정식 배포를 준비하기 위한 브랜치입니다.
• develop 브랜치에서 분기하며, 배포 전 최종적인 버그 수정 및 QA를 진행합니다.
• 테스트 중 발견된 버그는 이 브랜치에서 직접 수정한 후, master(main)와 develop 브랜치 양쪽에 모두 병합됩니다.

Hotfix 브랜치

• 프로덕션 환경에서 발생한 긴급 버그를 수정하기 위한 브랜치입니다.
• 가장 안정적인 master(main) 브랜치에서 직접 분기합니다.
• 수정이 완료되면 즉시 master(main)와 develop 브랜치로 병합하여 다음 릴리스에도 수정 사항이 반영되도록 합니다.

Semantic Versioning (SemVer) - x.y.z

SemVer는 버전 번호를 통해 변경 사항의 성격을 명확히 전달하는 규칙입니다.

• Major (x): 기존 버전과 호환되지 않는 큰 변경이 발생했을 때 증가합니다. (예: 1.5.2 → 2.0.0)
• Minor (y): 하위 버전과 호환되는 새로운 기능이 추가되었을 때 증가합니다. (예: 1.1.8 → 1.2.0)
• Patch (z): 하위 버전과 호환되는 버그 수정 등 작은 변경이 있을 때 증가합니다. (예: 1.0.1 → 1.0.2)

---

2. 대표적인 Git 브랜치 전략 3가지

Git Flow

안정적인 배포 주기를 가진 대규모 프로젝트에 적합한 전통적이고 체계적인 전략입니다.

• 주요 브랜치: master, develop, feature, release, hotfix 등 위에서 설명한 대부분의 브랜치를 활용합니다.
• 작업 흐름:
  1. master에서 시작된 develop 브랜치를 기준으로 feature 브랜치를 생성하여 기능을 개발합니다.
  2. 기능 개발 완료 후, Pull Request를 통해 코드 리뷰를 거쳐 develop 브랜치에 병합합니다.
  3. 배포 시점이 되면 develop 브랜치에서 release 브랜치를 분기하여 QA를 진행합니다.
  4. QA가 완료되면 release 브랜치를 master와 develop에 모두 병합하고, master 브랜치에 버전 태그를 추가하여 배포합니다.
  5. 배포 후 긴급 버그는 hotfix 브랜치를 통해 해결합니다.
• 장점: 역할이 명확하게 분리되어 코드의 안정성을 높게 유지할 수 있습니다.
• 단점: 브랜치가 많아 관리 리소스가 많이 들고, 절차가 복잡하여 긴급 배포에 유연하게 대처하기 어렵습니다.

GitHub Flow

Git Flow를 단순화한 모델로, 빠른 개발과 지속적인 배포(CI/CD)를 지향하는 프로젝트에 적합합니다.

• 주요 브랜치: main(또는 master)과 feature 브랜치, 단 두 종류만으로 운영됩니다.
• 작업 흐름:
  1. 기능 개발, 버그 수정 등 모든 작업은 main 브랜치에서 새로 생성한 feature 브랜치에서 시작합니다.
  2. 개발이 완료되면 Pull Request를 생성하여 팀원들의 리뷰를 받습니다.
  3. 충분한 논의와 테스트를 거쳐 안전하다고 판단되면 main 브랜치로 즉시 병합하고 배포합니다.
• 장점: 워크플로우가 매우 간단하여 빠르고 직관적입니다.
• 단점: main 브랜치에 대한 충분한 검증 절차가 없다면 불안정한 코드가 배포될 위험이 있습니다.

Trunk-based Development (TBD)

단일 메인 브랜치(trunk, 보통 main)를 중심으로 모든 개발을 진행하는 전략입니다. GitHub Flow보다 더 극단적으로 빠른 통합과 배포를 추구합니다.

• 주요 브랜치: 거의 모든 작업이 trunk 브랜치 하나를 중심으로 이루어집니다.
• 작업 흐름:
  1. 개발자들은 매우 짧은 수명(보통 하루 미만)의 브랜치를 만들어 작업합니다.
  2. 작업이 완료되면 코드 리뷰 후 즉시 trunk 브랜치에 병합합니다.
  3. 모든 개발자가 하루에도 여러 번 trunk에 코드를 통합(Integration)합니다.
• 장점:
  • 브랜치 관리 리소스가 거의 들지 않고, 배포 속도가 매우 빠릅니다.
  • 코드 통합이 빈번하여 충돌 발생이 적고, 코드 리뷰가 수월합니다.
• 단점:
  • 완성되지 않은 기능이 trunk에 병합될 수 있어 기능 플래그(Feature Flag)와 같은 추가적인 관리가 필요합니다.
  • 몇 주 이상 걸리는 큰 기능 개발에는 적합하지 않을 수 있습니다.

---

3. 실제 오픈소스 프로젝트의 브랜치 전략

• Django (파이썬 웹 프레임워크)
  • 전략: Semantic Versioning을 기반으로 stable/x.x.x 형태의 브랜치를 운영하며 안정성을 최우선으로 합니다.
  • 특징: Pull Request를 통해 모든 기능 개발과 버그 수정이 엄격하게 관리됩니다. 장기간 유지보수되는 대규모 프로젝트답게 안정적인 릴리스 주기에 초점을 맞춥니다.
• Pytorch (AI 프레임워크)
  • 전략: 매우 동적인 브랜치 구성을 가집니다. gh/{username}/{PR번호}/{head}와 같은 패턴이 관찰됩니다.
  • 특징: AI 분야의 빠른 개발 속도에 맞춰 수많은 오픈소스 기여자들이 PR로 코드를 올리면, 운영진이 이를 검토하고 통합하여 배포하는 방식을 취합니다.
• Storybook (UI 컴포넌트 도구)
  • 전략: 유연한 전략을 취합니다. {username}/{feature} 형태의 기능 개발 브랜치와 함께 hotfix, next-release 등 다양한 목적의 브랜치를 함께 사용합니다.
  • 특징: 엄격한 규칙보다는 장기적인 유지보수와 신규 기능 개발의 균형을 맞춥니다. 버그 발생 시 hotfix 브랜치로 빠르게 대응하여 사용자 신뢰를 확보합니다.

결론

Git 브랜치 전략을 잘 이해하고 프로젝트의 특성에 맞게 활용하는 것은 매우 중요합니다. 이는 코드 변경 사항을 투명하게 공유하고, 코드 품질을 높이며, 팀의 업무 현황을 명확히 파악하는 데 도움을 줍니다. 궁극적으로 효율적인 협업을 통해 프로젝트의 생산성을 크게 향상시킬 수 있습니다.