Skip to content

Git Workflow

Jump to bottom
이재영 edited this page Dec 1, 2025 · 2 revisions

브랜치 전략

main ← dev ← 기타 브랜치 구조를 기본으로 한다.

1. main 브랜치

  • 항상 배포 가능한 상태로 유지된다.
  • 배포 시 태그를 사용해 릴리즈 버전 관리 (예: v1.0.0)

2. dev 브랜치

  • 통합 개발 브랜치 역할.
  • 직접 커밋 및 직접 푸시 금지 → 반드시 PR + 동료의 코드 리뷰 및 approval 후 머지
  • 기능 개발 / 버그 수정 등 모든 작업은 dev에서 분기해서 dev로 다시 머지한다.
  • 안정화된 시점에 release 브랜치를 통해 main과 동기화한다.

3. 기타 브랜치

작업 목적에 따라 prefix를 구분하며, 모든 작업 브랜치는 dev에서 분기한다.

prefix 용도
feature/ 새로운 기능 개발
fix/ 버그 수정
hotfix/ 프로덕션 긴급 수정 (main에서 분기하여 main+dev 둘 다에 반영)
chore/ 빌드, 설정, 패키지 업데이트 등 기타 작업
refactor/ 코드 리팩토링
docs/ 문서 작업

브랜치 네이밍 포맷

git hook의 pre-push에서 브랜치 네이밍을 검사한다. 아래에서 해당 규칙들을 자세히 설명한다.

기본 포맷

<prefix>/<work-description>
  • work-description은 영어 소문자, 단어는 -로 연결

커밋 메시지 포맷

Conventional Commits 스타일을 기반으로 한다.

기본 형식

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

<body>   # optional
<footer> # optional
  • subject: 변경의 요약 (현재형/명령형으로 작성)
  • scope: 변경이 적용되는 플랫폼을 명시 (Android, iOS, Windows, Macos) - 생략 가능

주요 type 목록

  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • docs: 문서 수정
  • style: 스타일링 수정 (비즈니스 로직을 제외한 단순 UI 변경)
  • refactor: 리팩토링
  • test: 테스트 추가/수정
  • chore: 기타 작업

예시

feat(Android): Toast 기능 추가

fix: handle null response on login

refactor: Avatar 컴포넌트를 AvatarGroup의 AvatarItem과 분리하여 별개 파일로 작성

chore: 린트 적용 및 번역 텍스트 추가

PR 규칙

1. PR 생성 규칙

  • 모든 작업 브랜치는 반드시 PR을 통해 dev 또는 main에 머지한다.
  • dev, main은 protected branch로 관리 → 직접 푸시 금지.

2. PR 대상 브랜치

  • 일반 작업: feature/*, fix/*, refactor/*, chore/* → dev로 PR
  • 릴리즈: release/x.y.z → 검증 후 main으로 PR
  • 핫픽스: hotfix/* → main에 PR + 동기화를 위해 dev에도 반영

3. PR 제목/설명 포맷

Github Actions의 “PR Title lint” workflow를 통해 PR 제목 형식을 자동으로 검증한다. PR 작성 시 해당 workflow를 통과하였는지 확인 요망.

제목 예시

[Feature] 카카오 소셜 로그인 기능 구현
[Fix] 안드로이드 로그인 크래시 수정

4. 코드 리뷰 & 머지 규칙

  • 동료의 approval 후 dev에 머지 가능
  • PR 본인이 제출한 PR은 승인 없이 self-merge 금지

5. 머지 방식

  • dev: Squash & Merge를 기본으로 함.

  • main: Merge Commit 또는 Fast-forward

    (릴리즈 이력을 명확하게 보존하기 위한 목적)

Clone this wiki locally