버전 관리: Git (DevOps 관점)

CI/CD 파이프라인의 출발점으로서의 Git — 왜 버전 관리가 DevOps의 기반인지, 파이프라인을 좌우하는 브랜치 전략은 무엇인지.

CI/CD 파이프라인의 출발점으로서의 Git — 왜 버전 관리가 DevOps의 기반인지, 파이프라인을 좌우하는 브랜치 전략은 무엇인지.

목표: 팀의 배포 흐름에 맞는 버전 관리 전략을 선택·설명할 수 있는 수준

[!info] 명령어 레퍼런스는 분리했습니다 이 문서는 DevOps 맥락(파이프라인·전략)에 집중합니다. Git 명령어 사용법은 아래 문서를 참고하세요.

Git-요약-정리 — 핵심 요약

Git-상세-가이드 — 명령어별 옵션·예시·트러블슈팅

00-MOC-Git — Git 노트 전체 지도

🎯 왜 Git이 DevOps의 기반인가

graph LR
    GIT["📁 Git<br/>(단일 진실 공급원)"] -->|"push 트리거"| CI["🔨 CI<br/>(빌드·테스트)"]
    CI -->|"성공"| CD["🚀 CD<br/>(배포)"]
    GIT -->|"선언적 상태"| GITOPS["🔄 GitOps<br/>(ArgoCD)"]
    GITOPS -->|"동기화"| K8S["☸️ Kubernetes"]

단일 진실 공급원(Single Source of Truth): 코드·설정·인프라(IaC)까지 Git에 두면 모든 변경이 추적·재현·롤백 가능
자동화의 트리거: push/PR/tag 이벤트가 파이프라인을 시작
협업과 리뷰: PR을 통한 코드 리뷰 = 품질 게이트
GitOps의 전제: Git 상태 = 배포 상태 → 03-01-GitOps-원칙

🌿 브랜치 전략 — 파이프라인을 결정한다

브랜치 전략은 곧 배포 흐름이다. 팀 규모와 릴리스 주기에 따라 선택한다.

GitHub Flow — 지속적 배포에 최적

graph LR
    MAIN["main (항상 배포 가능)"] -->|"브랜치"| FEAT["feature/*"]
    FEAT -->|"PR + CI"| REVIEW["리뷰"]
    REVIEW -->|"머지"| MAIN
    MAIN -->|"자동 배포"| PROD["Production"]

main은 항상 배포 가능, feature 브랜치 → PR → 머지 → 자동 배포
장점: 단순, 빠른 배포 / 적합: 웹 서비스, 소규모~중규모 팀

Git Flow — 명확한 릴리스 주기

graph TB
    MAIN["main (프로덕션)"] --> HOT["hotfix/*"]
    MAIN --> REL["release/*"]
    REL --> DEV["develop (통합)"]
    DEV --> FEAT["feature/*"]
    FEAT --> DEV
    DEV --> REL
    REL --> MAIN
    HOT --> MAIN

main/develop/feature/release/hotfix 5종 브랜치
장점: 버전 관리 명확 / 단점: 복잡, 지속적 배포와 상충 / 적합: 버전 릴리스 제품

Trunk-Based — 대규모·CI 성숙 팀

graph LR
    TRUNK["main (trunk)"] -->|"짧은 브랜치"| SHORT["feature (1~2일)"]
    SHORT -->|"자주 머지"| TRUNK
    TRUNK -->|"Feature Flag로 숨김"| PROD["Production"]

모두가 main에 짧게 사는 브랜치로 하루 단위 머지, 미완성은 Feature Flag로 숨김
장점: 통합 지옥 회피, CI/CD 궁합 최고 / 적합: 대규모, 높은 자동화 성숙도

전략 비교

전략	복잡도	배포 빈도	적합한 팀
GitHub Flow	낮음	높음(수시)	소·중규모, 웹 서비스
Git Flow	높음	낮음(주기적)	버전 릴리스 제품
Trunk-Based	중간	매우 높음	대규모, CI 성숙

🤝 PR과 품질 게이트

PR은 단순 머지 수단이 아니라 자동화된 품질 검문소다.

graph LR
    PR["Pull Request"] --> LINT["📏 Lint"]
    LINT --> TEST["🧪 Test"]
    TEST --> SCAN["🔒 Security Scan"]
    SCAN --> REVIEW["👀 Human Review"]
    REVIEW --> MERGE["🔀 Merge"]

브랜치 보호 규칙(Branch Protection): main 직접 push 금지, PR·CI 통과·리뷰 승인 필수
상태 체크(Status Checks): CI 그린 아니면 머지 차단
CODEOWNERS: 영역별 필수 리뷰어 지정
실제 구현 → 02-02-GitHub-Actions

✍️ 커밋 컨벤션과 자동화

일관된 커밋 메시지는 사람뿐 아니라 자동화 도구도 읽는다.

<type>(<scope>): <subject>

타입	의미
`feat`	새 기능 (MINOR 버전↑)
`fix`	버그 수정 (PATCH 버전↑)
`BREAKING CHANGE`	호환성 깨짐 (MAJOR 버전↑)
`docs`/`style`/`refactor`/`test`/`chore`	기타

시맨틱 버저닝 자동화: 커밋 타입으로 버전·CHANGELOG 자동 생성(semantic-release)
자세한 규칙·예시 → Git-상세-가이드#커밋 메시지 컨벤션 (Conventional Commits)

📋 체크리스트

Git이 CI/CD·GitOps의 기반인 이유 설명
팀 상황에 맞는 브랜치 전략 선택·근거 제시
GitHub Flow / Git Flow / Trunk-Based 비교
브랜치 보호 규칙 + 상태 체크 설정
PR을 품질 게이트로 활용
커밋 컨벤션 → 버전 자동화 연결
명령어 숙련 → Git-상세-가이드 체크리스트 참고

🔗 관련 노트

00-MOC-Git — Git 노트 전체 지도
Git-상세-가이드 — 명령어 완전판
01-01-CI-CD-개념 — CI/CD 파이프라인
02-02-GitHub-Actions — PR 자동화·브랜치 보호 구현
03-01-GitOps-원칙 — Git 기반 배포

마지막 업데이트: 2026-06-02