브랜치 네이밍 컨벤션

Git 브랜치 네이밍 컨벤션

기본 원칙 (공통)

•

소문자 사용

•

단어 구분은 /와 - 사용

•

의미가 한눈에 보이게

FeatureLogin, fix_bug

feature/login, fix/login-error

기본 구조 (표준)

&lt;type&gt;/&lt;scope&gt;-&lt;description&gt;
Plain Text
복사

예시

feature/auth-login
fix/order-payment
refactor/user-service
Plain Text
복사

브랜치 타입 (가장 중요)

타입	용도	예시
main	배포 기준	main
develop	개발 통합	develop
feature	기능 개발	feature/signup
fix	버그 수정	fix/login-error
hotfix	긴급 수정	hotfix/payment
refactor	리팩토링	refactor/auth
test	테스트	test/user-api
docs	문서	docs/readme
chore	기타	chore/gradle-update
release	배포 준비	release/1.0.0

Scope & Description 작성법

•

기능/모듈/이슈 중심

•

동사 , 명사/의미 중심 

feature/user-profile
fix/session-timeout
Plain Text
복사

이슈 번호 포함 (협업 권장)

feature/123-login
fix/#45-null-pointer
Plain Text
복사

또는

feature/login-123
Plain Text
복사

실무에서 가장 많이 쓰는 패턴

Git Flow

main
develop
feature/*
release/*
hotfix/*
Plain Text
복사

GitHub Flow (단순)

main
feature/*
fix/*
Plain Text
복사

혼자 프로젝트 (추천)

main
feature/*
Plain Text
복사

피해야 할 네이밍

test1
mybranch
aaa
temp
Plain Text
복사

나중에 절대 기억 못함

예시 모음

feature/login
feature/signup-email
fix/auto-login
hotfix/security-patch
refactor/db-structure
docs/api-guide
Plain Text
복사

한 줄 요약

브랜치 이름만 봐도 "무슨 작업인지" 알 수 있어야 한다

main / stage / develop 브랜치 전략

graph LR
    A["develop<br/>개발"] --> B["stage<br/>검증"]
    B --> C["main<br/>운영"]
    
    style A fill:#4CAF50,color:#fff
    style B fill:#FF9800,color:#fff
    style C fill:#F44336,color:#fff
Mermaid
복사

기본 브랜치 구조 (3단계)

main     → 운영(Production)
stage    → 스테이징 / 검증(QA)
develop  → 개발 통합
Plain Text
복사

각 브랜치 역할

main

•

실제 서비스 운영 브랜치

•

배포 이력만 존재

•

직접 커밋 

stage

•

운영 배포 전 최종 검증

•

QA / 기획 / 고객 테스트

•

운영과 환경 거의 동일

develop

•

개발자들이 기능을 합치는 브랜치

•

feature 병합 대상

작업 브랜치 규칙

기능 개발

feature/login
feature/signup
Plain Text
복사

기준: develop

버그 수정

fix/session-timeout
Plain Text
복사

기준: develop

긴급 운영 수정

hotfix/payment-error
Plain Text
복사

기준: main

브랜치 흐름 (중요)

feature/*  → develop
develop    → stage
stage      → main
Plain Text
복사

흐름 예시

feature/login  → develop
develop        → stage
stage          → main
Plain Text
복사

배포 & 병합 전략

단계	방식
feature → develop	merge / rebase
develop → stage	merge commit
stage → main	merge commit
hotfix → main	merge commit

버전 태그 (권장)

git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0
Bash
복사

main 브랜치에서만 태그

네이밍 컨벤션 요약

main
stage
develop
feature/*
fix/*
hotfix/*
release/*
Plain Text
복사

실무에서 이 구조가 좋은 이유

•

배포 사고 최소화

•

QA 단계 명확

•

롤백 쉬움

•

CI/CD 파이프라인 분리 가능

예시 CI/CD 매핑 (참고)

브랜치	배포
develop	개발 서버
stage	스테이징 서버
main	운영 서버

한 줄 요약

graph LR
    A["develop<br/>개발"] --> B["stage<br/>검증"]
    B --> C["main<br/>운영"]
    
    style A fill:#4CAF50,color:#fff
    style B fill:#FF9800,color:#fff
    style C fill:#F44336,color:#fff
Mermaid
복사

graph TD
    A["feature/*"] -->|merge| B["develop"]
    B -->|검증 요청| C["stage"]
    C -->|최종 승인| D["main"]
    D -->|긴급 수정| E["hotfix/*"]
    E -->|즉시 배포| D
    E -.->|반영| B
    
    style B fill:#4CAF50
    style C fill:#FF9800
    style D fill:#F44336
    style A fill:#2196F3
    style E fill:#9C27B0
Mermaid
복사

이 구조는 SI / 외주 / 기업 프로젝트에서 가장 많이 쓰는 패턴입니다.