GitLab Flow

GitLab Flow는 GitLab에서 제안한 브랜치 전략으로, 기능 중심 개발과 이슈 추적을 통합하여 소프트웨어 개발을 간소화한다. 이는 GitFlow의 복잡성을 줄이고, GitHub Flow의 단순함을 유지하면서도 다양한 배포 환경을 지원하는 유연성을 제공한다.

핵심 개념

GitLab Flow의 핵심 개념은 다음과 같다:

  1. 업스트림 퍼스트(Upstream First): 항상 상위 환경으로 먼저 병합하는 원칙
  2. 이슈 추적 통합: GitLab 이슈와 머지 리퀘스트(MR)의 긴밀한 연계
  3. 상황별 워크플로우: 프로젝트 특성에 따라 선택 가능한 세 가지 모델
  • 메인 브랜치:
    • main: 배포 가능한 코드 보유.
  • 환경 브랜치: 개발, 스테이징, 프로덕션 등 각 배포 환경에 대응하는 장수 브랜치
    • staging, pre-prod, production: 단계별 테스트 및 배포.
  • 기능 브랜치: 새로운 기능 개발을 위한 단기 브랜치
    • feature/*: 기능 개발 후 main에 병합.
  • 풀 리퀘스트: 코드 리뷰 및 병합 프로세스.
graph TD
    main[main 브랜치] -->|분기| feature[feature/기능]
    feature -->|풀 리퀘스트| main
    main -->|병합| staging[staging]
    staging -->|병합| pre-prod[pre-prod]
    pre-prod -->|병합| production[production]

▲ GitLab Flow 환경 브랜치 워크플로우[3][6]

Gitlab Flow
https://www.linkedin.com/pulse/gitlab-flow-jadson-santos

목적

  • 다양한 배포 환경 관리의 단순화
  • Git Flow의 복잡성 제거
  • GitHub Flow의 제한점 보완
  • 지속적 배포와 전통적 릴리스 관리 통합
  • 팀 협업과 코드 품질 향상

필요성

  • 여러 환경(개발, 스테이징, 프로덕션)을 가진 프로젝트 관리
  • 버전 릴리스가 필요한 제품 개발
  • SaaS와 패키지 소프트웨어 개발 방식 통합
  • 엔터프라이즈 수준의 배포 프로세스 요구
  • 규정 준수가 필요한 산업군의 요구사항 충족

주요 기능

  1. 환경별 브랜치 관리: 배포 환경에 맞춘 브랜치 전략
  2. 머지 리퀘스트(MR): 코드 리뷰 및 CI/CD 통합
  3. 이슈 기반 개발: 이슈와 코드 변경사항 연결
  4. 체리픽(Cherry-pick): 특정 커밋만 선택적으로 적용
  5. 보호된 브랜치: 중요 브랜치의 직접 수정 방지
  6. 자동화된 배포: GitLab CI/CD와의 완벽한 통합

핵심 원칙

  • 모든 코드 변경은 이슈 트래킹 시스템과 연결
  • main 브랜치는 항상 안정적이고 배포 가능한 상태 유지
  • 환경별로 명확한 테스트 및 배포 절차 준수
  • Merge Request를 통한 코드 리뷰 필수

특징

  • Git Flow의 복잡성을 줄이고, GitHub Flow의 단순성을 결합
  • 환경별 브랜치 전략 채택
  • 지속적 배포와 안정성 균형
  • 단방향 워크플로우
    • main → staging → pre-production → production
  • 개발, 스테이징, 프로덕션 환경을 위한 브랜치 구조 지원

주요 원리

GitLab Flow의 세 가지 주요 워크플로우 모델:

환경 브랜치를 사용한 GitLab Flow

GitLab Flow는 기능 브랜치에서 개발을 진행하고, 완료된 기능은 Merge Request를 통해 메인 브랜치에 병합된다. 이후, 메인 브랜치의 코드는 스테이징 브랜치를 거쳐 프로덕션 브랜치로 병합되며, 각 단계에서 자동화된 테스트와 배포가 이루어진다.
환경별 브랜치로 각 배포 환경을 명확히 분리해 개발, 테스트, 운영의 안정성 확보
자동화된 CI/CD 파이프라인으로 각 브랜치 병합 시 테스트 및 배포가 자동 실행

1

feature → main → pre-production → production

1
2
3
4
5

    ┌─────────────┐     ┌──────────────┐     ┌────────────────┐     ┌────────────┐
    │   Feature   │ --> │     Main     │ --> │   Pre-Prod     │ --> │ Production │
    │   Branches  │     │   (Active    │     │ (Staging Env)  │     │ (Live Env) │
    └─────────────┘     │ Development) │     └────────────────┘     └────────────┘
                        └──────────────┘
브랜치 전략
1
2
3
4
5
6
7

main (기본 개발 브랜치)
├── staging (QA/테스트 환경)
├── production (운영 환경)
└── feature/* (기능 개발)
    ├── feature/TECH-123-user-authentication
    ├── feature/TECH-456-payment-integration
    └── feature/TECH-789-shopping-cart
워크플로우

  1. 이슈 생성: GitLab 이슈에서 작업 티켓 생성

  2. 기능 브랜치 생성: main에서 분기

    1

    git checkout -b feature/issue-123-user-auth

  3. 개발 및 커밋: 기능 개발 및 정기적 커밋

  4. 머지 리퀘스트(MR) 생성: 코드 리뷰 요청

  5. CI/CD 파이프라인 실행: 자동화된 테스트 및 빌드

  6. 코드 리뷰 및 토론: 팀원 피드백

  7. main 브랜치 병합: 승인 후 병합

  8. 환경 브랜치로 전파: pre-production → production 순차 병합

  9. 배포 및 모니터링: 각 환경별 배포 실행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

GitLab Flow 실제 적용 사례:

┌─────────────────────────────────────────────────────────────────┐
│                 핀테크 모바일 뱅킹 앱 워크플로우                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│    [이슈] ─→ [Feature Branch] ─→ [MR + 보안 검사]             │
│                   │                      │                      │
│                   ▼                      ▼                      │
│              [develop] ─────────→ [staging]                     │
│                   │                      │                      │
│                   │                      ▼                      │
│                   │                  [UAT 환경]                 │
│                   │                      │                      │
│                   │                      ▼                      │
│                   │               [Compliance Check]            │
│                   │                      │                      │
│                   │                      ▼                      │
│                   └──────────────→ [production]                 │
│                                          │                      │
│                                          ▼                      │
│                                  [Production Deploy]            │
│                                          │                      │
│                                          ▼                      │
│                                  [Monitoring & Alerts]          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

기능:
- 모든 코드 변경은 보안 검사 필수
- 각 환경별 자동화된 테스트 스위트
- UAT 환경에서 규제 준수 검증
- 프로덕션 배포 후 자동 모니터링

릴리스 브랜치를 사용한 GitLab Flow

릴리스 브랜치 모델은 외부 배포가 필요한 프로젝트(예: 오픈소스 라이브러리, 엔터프라이즈 소프트웨어)에 최적화된 전략이다.

1

feature → main → release-X.Y → (태그)

1
2
3
4
5
6
7
8
9

    ┌─────────────┐     ┌──────────────┐     ┌────────────────┐
    │   Feature   │ --> │     Main     │ --> │ Release-X.Y    │
    │   Branches  │     │   (Develop)  │     │ (Stable Ver)   │
    └─────────────┘     └──────────────┘     └────────────────┘
                                                     │
                                                     ▼
                                              ┌────────────┐
                                              │ Tags (v1.0)│
                                              └────────────┘
브랜치 전략
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

main (개발 브랜치)
├── release-1.0 (v1.0.x 릴리스 브랜치)
│   └── tags: v1.0.0, v1.0.1, v1.0.2
├── release-1.1 (v1.1.x 릴리스 브랜치)
│   └── tags: v1.1.0, v1.1.1
├── release-2.0 (v2.0.x 릴리스 브랜치)
│   └── tags: v2.0.0
└── feature/* (기능 개발 브랜치)
    ├── feature/DM-123-query-optimizer
    ├── feature/DM-456-backup-restore
    └── feature/DM-789-connection-pool
워크플로우

1. 기능 개발 및 main 병합

  • feature/oauth 브랜치에서 OAuth 2.0 지원 기능 개발

  • 완료 후 main 브랜치로 Pull Request(MR) 생성 → 코드 리뷰 → 병합

    1
2

    git checkout main
git merge feature/oauth --no-ff  # --no-ff로 병합 커밋 명시적 생성

2. 릴리스 브랜치 생성

  • 버전 2.3 릴리스 준비 시점에 main에서 release-2.3 브랜치 분기

    1
2
3
4

    git checkout main
git pull origin main
git checkout -b release-2.3
git push origin release-2.3

3. 릴리스 테스트 및 버그 수정

  • release-2.3 브랜치에서 QA 수행

  • 발견된 버그는 업스트림 퍼스트 원칙 적용:

    1. main 브랜치에 먼저 수정 커밋
    2. release-2.3 브랜치로 체리픽(cherry-pick)
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

    # main에서 버그 수정
git checkout main
git checkout -b hotfix/auth-bug
# ... 수정 작업 ...
git commit -m "fix: OAuth 토큰 검증 로직 개선"
git checkout main
git merge hotfix/auth-bug

# release-2.3에 체리픽
git checkout release-2.3
git cherry-pick [커밋 해시]

4. 버전 태그 생성 및 배포

  • 모든 테스트 통과 후 release-2.3 브랜치에 태그 추가

    1
2

    git tag -a v2.3.0 -m "Release version 2.3.0"
git push origin v2.3.0

  • 태그를 기반으로 운영 환경에 배포 (예: Docker 이미지 빌드)

5. 릴리스 브랜치 종료

  • release-2.3 브랜치를 main에 병합 (필요시)
  • 이후 추가 패치는 release-2.3.x 브랜치에서 관리

Main 브랜치만 사용하는 GitLab Flow (GitHub Flow와 유사)

1

feature → main → (자동 배포)

1
2
3
4
5

    ┌─────────────┐     ┌──────────────┐     ┌────────────────┐
    │   Feature   │ --> │     Main     │ --> │ Auto Deploy    │
    │   Branches  │     │   (Always    │     │ to Production  │
    └─────────────┘     │ Deployable)  │     └────────────────┘
                        └──────────────┘

장점과 단점

구분항목설명
✅ 장점유연성프로젝트 특성에 따라 세 가지 모델 중 선택 가능
환경 관리다중 환경(개발, 스테이징, 프로덕션) 효과적 관리
통합성GitLab 플랫폼의 모든 기능과 원활한 통합
단순화Git Flow 대비 복잡성 감소, GitHub Flow 대비 기능 확장
안정성환경별 브랜치로 안정적인 배포 프로세스
CI/CD 최적화GitLab CI/CD와 완벽한 통합으로 자동화 극대화
⚠ 단점학습 곡선GitHub Flow보다 복잡한 구조로 초기 학습 필요
브랜치 관리여러 환경 브랜치 관리로 인한 오버헤드
병합 충돌장기 환경 브랜치로 인한 병합 충돌 가능성
GitLab 종속성GitLab 플랫폼 기능에 최적화되어 있음

분류에 따른 종류 및 유형

분류 기준유형특징적용 사례
배포 전략환경 브랜치 모델main → pre-prod → production엔터프라이즈 애플리케이션
릴리스 브랜치 모델main → release-X.Y → tags버전 릴리스가 필요한 제품
지속적 배포 모델main → auto deploySaaS, 웹 애플리케이션
프로젝트 규모소규모 프로젝트용main 브랜치 중심 단순 모델스타트업, POC 프로젝트
중대규모 프로젝트용환경 브랜치 활용 모델기업용 소프트웨어
대규모 프로젝트용릴리스 + 환경 브랜치 복합 모델글로벌 서비스, 플랫폼
산업별금융/의료엄격한 환경 분리, 감사 추적뱅킹 시스템, 헬스케어 앱
IT/테크빠른 배포, 지속적 통합SaaS, 클라우드 서비스
제조/임베디드릴리스 중심, 버전 관리IoT 디바이스, 산업용 SW

실무 적용 예시

상황적용 방법기대 효과주의사항
다중 환경 관리main → staging → production 브랜치 구성각 환경별 안정성 보장환경 간 설정 차이 문서화
버전 릴리스release-1.0, release-2.0 브랜치 활용명확한 버전 관리장기 지원 버전 전략 수립
긴급 버그 수정hotfix 브랜치 → production 직접 병합신속한 문제 해결모든 환경에 역전파 필수
대규모 기능 개발에픽 브랜치 → 피처 브랜치 계층 구조복잡한 기능 체계적 관리정기적 main 브랜치 동기화
CI/CD 통합.gitlab-ci.yml 파일로 파이프라인 정의자동화된 품질 관리환경별 변수 설정 관리

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

고려사항세부내용권장사항피해야 할 점
브랜치 전략 선택프로젝트 특성 분석팀 규모와 배포 빈도 고려과도하게 복잡한 전략 채택
환경 구성개발/스테이징/프로덕션 설정환경별 설정 자동화수동 환경 설정 의존
MR 프로세스코드 리뷰 정책 수립템플릿 활용, 자동 체크 설정리뷰 없는 직접 병합
CI/CD 파이프라인단계별 자동화 구성병렬 실행으로 속도 최적화테스트 커버리지 부족
이슈 추적GitLab Issues 활용레이블, 마일스톤 체계화이슈와 코드 연결 누락
브랜치 보호Protected Branches 설정최소 승인자 수 지정모든 브랜치 과도한 보호

최신 동향

주제항목설명
AI 통합GitLab Duo AIAI 기반 코드 리뷰 및 MR 자동 생성
자동 충돌 해결AI가 머지 충돌 해결 방안 제시
DevSecOps보안 스캔 강화SAST, DAST, 종속성 스캔 통합
컴플라이언스 자동화규제 준수 자동 검증 파이프라인
클라우드 네이티브Kubernetes 통합GitOps 워크플로우 지원 강화
멀티 클라우드 배포AWS, Azure, GCP 동시 배포 관리
성능 최적화대규모 모노레포 지원수천 개 프로젝트 효율적 관리
분산 CI 실행지역별 빌드 최적화

주목해야 할 기술

주제항목설명
AI/MLGitLab ML Ops머신러닝 모델 버전 관리 통합
예측적 배포AI 기반 배포 위험도 분석
보안SBOM 자동 생성소프트웨어 구성 요소 자동 추적
Zero Trust CI/CD모든 파이프라인 단계 인증 강화
개발자 경험Remote Development클라우드 기반 개발 환경
Visual Studio Code 통합IDE 내 완전한 GitLab 워크플로우

앞으로의 전망

주제항목설명
자동화 확대완전 자동화 워크플로우AI가 브랜치 전략 최적화 제안
자가 치유 파이프라인실패 시 자동 복구 메커니즘
플랫폼 통합All-in-One DevOps개발부터 운영까지 단일 플랫폼
생태계 확장써드파티 도구 깊은 통합
보안 중심Shift-Left Security개발 초기 단계부터 보안 통합
실시간 취약점 감지코드 작성 중 보안 이슈 탐지

하위 주제로 분류한 추가 학습 내용

카테고리주제간략한 설명
브랜치 관리환경 브랜치 전략개발, 스테이징, 프로덕션 브랜치 구성
릴리스 브랜치 활용버전 릴리스를 위한 브랜치 관리
GitLab CI/CD.gitlab-ci.yml 작성파이프라인 정의 및 구성 방법
파이프라인 최적화캐싱, 병렬화, 아티팩트 관리
머지 리퀘스트MR 템플릿 작성표준화된 MR 프로세스 구축
코드 리뷰 가이드라인효과적인 리뷰 문화 정착
보안 통합SAST/DAST 설정정적/동적 보안 분석 구성
컨테이너 스캔Docker 이미지 취약점 검사

관련 분야 추가 학습 내용

관련 분야주제간략한 설명
DevOpsGitOps 방법론Git을 통한 인프라 관리
ArgoCD 통합Kubernetes 배포 자동화
프로젝트 관리GitLab 프로젝트 관리이슈, 에픽, 마일스톤 활용
애자일 보드 사용칸반, 스크럼 보드 구성
모니터링Prometheus 통합메트릭 수집 및 모니터링
Grafana 대시보드시각화 및 알림 설정
보안DevSecOps 실천보안을 개발 프로세스에 통합
컴플라이언스 자동화GDPR, SOC2 준수 자동화

용어 정리

용어설명
CI/CD지속적 통합/배포(Continuous Integration & Delivery)
OCI(Open Container Initiative)컨테이너 표준화 규격
Merge Request (MR)GitLab에서 코드 변경사항을 검토하고 병합하기 위한 요청
Environment Branches개발, 스테이징, 프로덕션 등 배포 환경별로 구분된 브랜치
Protected Branches직접 푸시를 방지하고 특정 규칙을 적용한 보호된 브랜치
GitLab CI/CDGitLab에 내장된 지속적 통합/배포 도구
Cherry-pick특정 커밋만 선택적으로 다른 브랜치에 적용하는 작업
Upstream First항상 상위 환경 브랜치로 먼저 병합하는 원칙
GitLab RunnerGitLab CI/CD 작업을 실행하는 에이전트
브랜치Git에서 코드의 변경 사항을 관리하기 위한 분기입니다.
스테이징 환경프로덕션 배포 전 테스트를 위한 환경입니다.

참고 및 출처