GitLab Flow 이해하기

main (개발 통합 브랜치)
  ↓
staging (스테이징 환경)
  ↓
pre-production (사전 프로덕션 환경, 선택사항)
  ↓
production (프로덕션 환경)

1. Issue 생성
   ↓
2. Feature 브랜치 생성 (main에서 분기)
   ↓
3. 코드 작성 및 커밋
   ↓
4. Merge Request 생성
   ↓
5. 코드 리뷰 및 CI 테스트
   ↓
6. main 브랜치에 병합
   ↓
7. main → staging 병합 (자동 배포)
   ↓
8. staging 환경 테스트
   ↓
9. staging → pre-production 병합 (선택)
   ↓
10. pre-production → production 병합
    ↓
11. 태그 생성 및 Feature 브랜치 삭제

Feature Branch          Main Branch         Staging Branch      Production Branch
─────────────────────────────────────────────────────────────────────────────────

feature/user-login
  │
  ├─ commit
  │
  ├─ commit
  │
  └─ Merge Request
         │
         └────────> main
                     │
                     ├─ CI 테스트 통과
                     │
                     └───────────> staging
                                    │
                                    ├─ QA 테스트
                                    │
                                    └──────────────> production
                                                      │
                                                      └─ v1.2.0 태그

# main에서 새 feature 브랜치 생성
git checkout main
git pull origin main
git checkout -b feature/user-authentication
 
# 작업 수행
git add .
git commit -m "feat: 사용자 인증 기능 추가"
 
# 원격 저장소에 푸시
git push origin feature/user-authentication

# GitLab UI에서 Merge Request 생성
# 코드 리뷰 및 승인 후 main으로 병합
 
# main 브랜치 업데이트
git checkout main
git pull origin main

# staging 환경으로 배포
git checkout staging
git merge main
git push origin staging
 
# 테스트 후 production으로 배포
git checkout production
git merge staging
git push origin production
 
# 릴리스 태그 생성
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0

# ❌ 잘못된 방법: production에서 직접 수정
git checkout production
git checkout -b hotfix/critical-bug
# ... 수정 작업
git checkout production
git merge hotfix/critical-bug
 
# ✅ 올바른 방법: main에서 수정 후 downstream
git checkout main
git checkout -b hotfix/critical-bug
# ... 수정 작업
 
# main에 먼저 병합
git checkout main
git merge hotfix/critical-bug
 
# staging에 병합
git checkout staging
git merge main
 
# production에 병합
git checkout production
git merge staging

main → staging → pre-production → production

main
  ├─ release/v1.0
  ├─ release/v1.1
  └─ release/v2.0

1. Issue 생성: "사용자 로그인 기능 추가 (#123)"
 
2. Feature 브랜치 생성: feature/123-user-login
 
3. 커밋 메시지에 Issue 번호 포함:
   git commit -m "feat: 로그인 폼 UI 추가 (#123)"
 
4. Merge Request 생성 시 자동으로 Issue와 연결
 
5. main에 병합되면 Issue 자동 종료

1. 개발자가 feature 브랜치에서 작업
   ↓
2. MR 생성 및 리뷰어 지정
   ↓
3. 자동 CI/CD 파이프라인 실행
   ├─ 빌드
   ├─ 단위 테스트
   ├─ 코드 품질 검사
   └─ 보안 스캔
   ↓
4. 코드 리뷰
   ├─ 피드백 반영
   └─ 승인
   ↓
5. main에 병합 (Squash & Merge 권장)
   ↓
6. Feature 브랜치 자동 삭제

# 1. 결제 기능 개발
git checkout -b feature/payment-integration
# ... 개발 작업
git push origin feature/payment-integration
 
# 2. Merge Request 생성 및 main 병합
# GitLab UI에서 MR 생성 → 코드 리뷰 → 승인 → 병합
 
# 3. staging 배포
git checkout staging
git merge main
git push origin staging
# 자동 배포 파이프라인 실행 → https://staging.example.com
 
# 4. QA 테스트 수행 및 승인
 
# 5. production 배포
git checkout production
git merge staging
git push origin production
# 자동 배포 파이프라인 실행 → https://example.com
 
# 6. 릴리스 태그 생성
git tag -a v2.3.0 -m "결제 기능 추가"
git push origin v2.3.0

# 1. 새 기능 개발
git checkout main
git checkout -b feature/dark-mode
# ... 개발 및 main 병합
 
# 2. 릴리스 준비
git checkout -b release/2.0 main
git push origin release/2.0
 
# 3. 앱스토어 제출
# release/2.0 브랜치로 빌드 생성 및 제출
 
# 4. 검수 중 버그 발견
git checkout main
git checkout -b hotfix/crash-fix
# ... 버그 수정
 
# main에 먼저 병합
git checkout main
git merge hotfix/crash-fix
 
# release 브랜치에 cherry-pick
git checkout release/2.0
git cherry-pick <commit-hash>
git push origin release/2.0
 
# 5. 릴리스 태그 생성
git tag -a v2.0.1 -m "크래시 버그 수정"
git push origin v2.0.1

# 1. 송금 기능 개발
git checkout -b feature/wire-transfer
# ... 개발 및 main 병합
 
# 2. test 환경 배포 및 자동화 테스트
git checkout test
git merge main
git push origin test
# 자동화된 통합 테스트, E2E 테스트 실행
 
# 3. uat 환경 배포 및 비즈니스 사용자 테스트
git checkout uat
git merge test
git push origin uat
# 실제 비즈니스 시나리오 검증
 
# 4. pre-production 최종 검증
git checkout pre-production
git merge uat
git push origin pre-production
# 성능 테스트, 보안 검증
 
# 5. production 배포 (변경 관리 승인 후)
git checkout production
git merge pre-production
git push origin production
 
# 6. 릴리스 문서화
git tag -a v1.5.0 -m "송금 기능 추가 - 변경관리 #CHG-2024-001"
git push origin v1.5.0

Git Flow:
feature → develop → release → main (production)
                                ↑
                             hotfix

GitLab Flow:
feature → main → staging → production
          ↑
       모든 수정사항

GitHub Flow:
feature → main (= production)
         ↓
    즉시 프로덕션 배포

GitLab Flow:
feature → main → staging → production
         ↓        ↓          ↓
       개발 완료  테스트  실제 배포

복잡도 스펙트럼:
GitHub Flow (가장 단순) ← GitLab Flow (중간) ← Git Flow (가장 복잡)

유연성 스펙트럼:
Git Flow (낮음) ← GitHub Flow (중간) ← GitLab Flow (높음)

적합한 팀 크기:
GitHub Flow: 소규모 (1-5명)
GitLab Flow: 중소규모 (3-50명)
Git Flow: 대규모 (10명 이상)

릴리스 주기:
GitHub Flow: 수시 배포
GitLab Flow: 일간-주간
Git Flow: 주간-월간

□ 팀 전체에 GitLab Flow 개념 교육
□ 기존 워크플로우와의 차이점 이해
□ Upstream-first 원칙 공유
□ 브랜치 네이밍 컨벤션 결정

# 프로젝트에 필요한 환경 결정
- main: 개발 통합 (필수)
- staging: 내부 테스트 (권장)
- production: 실 서비스 (필수)
- pre-production: 최종 검증 (선택)
 
# 브랜치 생성
git checkout main
git checkout -b staging
git push origin staging
 
git checkout -b production
git push origin production

stages:
  - test
  - deploy-staging
  - deploy-production
 
# 테스트 (모든 MR에서 실행)
test:
  stage: test
  script:
    - npm install
    - npm run test
    - npm run lint
  only:
    - merge_requests
 
# Staging 배포 (staging 브랜치 푸시 시)
deploy-staging:
  stage: deploy-staging
  script:
    - echo "Deploying to staging..."
    - npm run build
    - npm run deploy:staging
  only:
    - staging
  environment:
    name: staging
    url: https://staging.example.com
 
# Production 배포 (production 브랜치 푸시 시)
deploy-production:
  stage: deploy-production
  script:
    - echo "Deploying to production..."
    - npm run build
    - npm run deploy:production
  only:
    - production
  environment:
    name: production
    url: https://example.com
  when: manual  # 수동 승인 필요

GitLab 설정에서 다음 브랜치 보호:
 
main 브랜치:
□ 직접 푸시 금지
□ Merge Request 필수
□ 최소 1명의 승인 필요
□ CI 테스트 통과 필수
□ Fast-forward 병합 금지
 
staging/production 브랜치:
□ 직접 푸시 금지
□ Maintainer만 병합 가능
□ CI 파이프라인 성공 필수

# 개발 프로세스
 
## 1. Issue 생성
모든 작업은 Issue 생성으로 시작합니다.
 
## 2. Feature 브랜치 생성
```bash
git checkout main
git pull origin main
git checkout -b feature/123-user-login

git add .
git commit -m "feat: 로그인 폼 추가 (#123)"

---

## 모범 사례

### 1. 브랜치 네이밍 컨벤션

```bash
# 기능 개발
feature/123-user-authentication
feature/456-payment-integration

# 버그 수정
fix/789-login-error
fix/101-cart-calculation

# Hotfix
hotfix/critical-security-patch
hotfix/payment-failure

# 문서화
docs/api-documentation
docs/readme-update

# 리팩토링
refactor/user-service
refactor/database-queries

# Conventional Commits 스타일 사용
feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 수정
style: 코드 포맷팅
refactor: 코드 리팩토링
test: 테스트 코드 추가/수정
chore: 빌드 프로세스 수정
 
# 예시
git commit -m "feat: 사용자 인증 API 추가 (#123)"
git commit -m "fix: 결제 실패 시 에러 처리 개선 (#456)"
git commit -m "docs: API 문서 업데이트"

## 변경 사항
<!-- 무엇을 변경했는지 -->
 
## 변경 이유
<!-- 왜 이 변경이 필요한지 -->
 
## 테스트 방법
<!-- 어떻게 테스트했는지 -->
 
## 스크린샷 (선택사항)
<!-- UI 변경이 있는 경우 -->
 
## 체크리스트
- [ ] 테스트 코드 작성
- [ ] 문서 업데이트
- [ ] 코드 리뷰 요청
- [ ] CI 테스트 통과
 
## 관련 Issue
Closes #123

# Semantic Versioning 사용
MAJOR.MINOR.PATCH
 
# 예시:
v1.0.0 - 초기 릴리스
v1.1.0 - 새 기능 추가 (하위 호환)
v1.1.1 - 버그 수정
v2.0.0 - Breaking change
 
# 태그 생성
git tag -a v1.2.0 -m "Release version 1.2.0
 
Features:
- 사용자 인증 개선
- 결제 모듈 추가
 
Fixes:
- 로그인 에러 수정
- 성능 최적화"
 
git push origin v1.2.0

# ❌ 잘못된 방법: downstream에서 직접 수정
git checkout staging
git checkout -b fix/bug
# 수정 후 staging에 병합
 
# ✅ 올바른 방법: main에서 수정 후 downstream
git checkout main
git checkout -b fix/bug
# 수정 및 테스트
 
# main에 먼저 병합
git checkout main
git merge fix/bug
 
# 순차적으로 downstream 병합
git checkout staging
git merge main
 
git checkout production
git merge staging

# staging에 병합 시 충돌 발생
git checkout staging
git merge main
# CONFLICT 발생
 
# 충돌 해결
git status  # 충돌 파일 확인
# 파일 편집하여 충돌 해결
git add <resolved-files>
git commit -m "Merge main into staging - resolve conflicts"
git push origin staging

# 1. main에서 hotfix 브랜치 생성
git checkout main
git checkout -b hotfix/critical-fix
 
# 2. 버그 수정 및 테스트
# ... 수정 작업
git add .
git commit -m "hotfix: 크리티컬 버그 수정"
 
# 3. main에 병합 (fast-track)
git checkout main
git merge hotfix/critical-fix
git push origin main
 
# 4. staging 생략하고 production으로 직접 병합 (긴급 시)
git checkout production
git merge main
git push origin production
 
# 5. 태그 생성
git tag -a v1.2.1 -m "Hotfix: 크리티컬 버그 수정"
git push origin v1.2.1
 
# 6. staging 동기화 (나중에)
git checkout staging
git merge main
git push origin staging