Git 브랜치 전략 완전 가이드

# Git 브랜치 전략 완전 가이드

Git을 쓴다면 브랜치 전략을 세워야 한다. 혼자 개발할 때는 몰랐다가 팀이 3명만 넘어가도 브랜치 관리가 엉망이 되는 경험을 한번쯤 해봤을 것이다. 브랜치 전략은 선택이 아니라 필수다.

## 주요 브랜치 전략 비교

### 1. Git Flow

Vincent Driessen이 2010년에 제안한 전통적인 전략. 다음 브랜치를 사용한다.

- `main` — 프로덕션 릴리즈만 병합
- `develop` — 다음 릴리즈를 위한 통합 브랜치
- `feature/*` — 기능 개발 (develop에서 분기)
- `release/*` — 릴리즈 준비 (QA, 버그 수정)
- `hotfix/*` — 프로덕션 긴급 수정 (main에서 직접 분기)

**장점:** 릴리즈 주기가 명확한 앱·SaaS에 적합. 버전 관리가 체계적이고 히스토리가 깔끔하다.

**단점:** 브랜치가 많아 복잡하다. CI/CD 환경에서 오버헤드가 크고, 소규모 팀에는 과도하게 무겁다. "장기 브랜치"가 생기면 머지 충돌이 잦아진다.

### 2. GitHub Flow

브랜치를 단순화한 전략. `main` + `feature/*` 두 가지만 사용한다.

1. `main`에서 브랜치 생성
2. 코드 작성 후 PR(Pull Request) 오픈
3. 리뷰 + CI 통과 후 `main`에 머지
4. 즉시 배포

**장점:** 단순하고 빠른 배포 사이클. CI/CD와 자연스럽게 연동된다.

**단점:** 여러 환경(staging/production)을 별도로 관리하기 어렵다.

### 3. GitLab Flow

GitHub Flow에 환경 브랜치를 추가한 절충안.

- `main` → staging 자동 배포
- `production` → 프로덕션 수동 배포
- `feature/*` → main으로 PR

Pre-production 테스트가 필요하고, staging 환경이 별도 있는 서비스에 적합하다.

### 4. Trunk-Based Development (TBD)

모든 개발자가 하루에도 여러 번 `main`(또는 `trunk`)에 직접 커밋하거나, 수명이 1~2일인 짧은 브랜치를 사용하는 방식.

**핵심 원칙:** Feature Flag로 미완성 코드를 숨기고, 지속적 통합을 극대화한다. 브랜치가 오래 살아있을수록 머지 충돌이 누적된다는 전제에서 출발한다.

**적합한 팀:** 강력한 빌드/테스트 자동화가 갖춰진 팀. Google, Facebook, Netflix 등 대형 테크 기업에서 채택.

## 실제 선택 기준

| 조건 | 추천 전략 |
|------|-----------|
| 릴리즈 주기가 정해진 앱/SaaS | Git Flow |
| 빠른 배포가 필요한 웹 서비스 | GitHub Flow |
| Staging 환경이 별도 있는 서비스 | GitLab Flow |
| 강력한 CI/CD + 대규모 팀 | Trunk-Based Development |
| 스타트업 초기 (1~3인) | GitHub Flow |

## 커밋 컨벤션 — Conventional Commits

브랜치 전략과 함께 커밋 메시지 규칙도 중요하다. **Conventional Commits** 스펙이 사실상 표준이다.

```
<type>(<scope>): <description>

feat(auth): add OAuth2 Google login
fix(api): handle null response from payment gateway
docs(readme): update setup instructions
refactor(db): extract query builder class
chore(deps): upgrade lodash to 4.17.21
```

주요 타입: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf`

이 컨벤션을 따르면 `CHANGELOG.md` 자동 생성, semantic versioning 자동화가 가능해진다.

## 머지 전략 선택

- **Merge commit**: 히스토리 완전 보존. PR 단위 작업이 명확하게 구분된다. 대형 팀에 적합.
- **Squash merge**: PR의 모든 커밋을 하나로 합쳐 main에 반영. `main` 히스토리가 깔끔해진다. 단, 개별 커밋 히스토리는 사라진다.
- **Rebase**: 선형 히스토리 유지. 로컬에서는 유용하나, **공유 브랜치에 절대 하지 말 것.** 팀원의 히스토리가 꼬인다.

## 브랜치 네이밍 규칙

```
feature/user-authentication
feature/JIRA-123-payment-gateway-v2
fix/null-pointer-on-login
hotfix/critical-payment-bug-2024-05
release/v2.1.0
```

일관된 네이밍은 자동화 스크립트(자동 배포, Jira 연동 등)를 쉽게 만든다.

## 보호 브랜치 설정 권장사항

- `main` / `production` 브랜치: 직접 push 금지
- 최소 1명 이상 리뷰 승인 필수
- CI 통과 필수 (status checks)
- 관리자도 예외 없음 (팀 규모 무관)

## CI/CD 파이프라인 연동 (by @techwheel)

브랜치 전략을 선택할 때 CI/CD 파이프라인과의 연동이 핵심 결정 요소다. 자동화 없는 브랜치 전략은 결국 사람 손에 의존하게 된다.

### GitHub Actions 예시 (GitHub Flow)

```yaml
# .github/workflows/ci.yml
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh
```

### 브랜치별 배포 환경 매핑 (GitLab Flow)

| 브랜치 | 배포 환경 | 조건 |
|--------|----------|------|
| `feature/*` → `main` 머지 | Staging | PR 머지 시 자동 |
| `main` → `production` 머지 | Production | 수동 승인 필요 |
| `hotfix/*` | Production | 자동 + Slack 알림 |

### Trunk-Based에서의 Feature Flags

```javascript
// config/features.js
module.exports = {
  newPaymentFlow: process.env.FEATURE_NEW_PAYMENT === 'true',
  aiRecommendations: process.env.FEATURE_AI_REC === 'true',
};

// 사용
if (features.newPaymentFlow) {
  // 새 결제 플로우 (미완성, prod에서 비활성화)
}
```

Feature Flag 없이 TBD를 하면 미완성 코드가 프로덕션에 나가는 사고가 발생한다. 이게 TBD의 가장 큰 운영 리스크다.

---
*@techwheel 보강 — 브랜치 전략이 좋아도 자동화가 없으면 사람 손에 의존하게 되어 결국 무너진다.*

Git branching strategies guide

// COMMENTS

ON THIS PAGE

Git branching strategies guide

// COMMENTS ↓ Newest First

ON THIS PAGE

// COMMENTS