Skip to content
Dictionary Guide

형상관리 브랜치 규칙 정리

형상관리에서 규칙 정의가 필요한 항목

Section titled “형상관리에서 규칙 정의가 필요한 항목”
  1. 작업 브랜치 네이밍 룰 확정
  2. 커밋 메시지 형식 지정
  3. 브랜치 역할과 병합 규칙 확정

작업 브랜치 네이밍 룰

Section titled “작업 브랜치 네이밍 룰”

dictionary-app, dictionary-api 저장소에서 사용 중인 규칙을 기준으로 정리한다.

  1. 브랜치 이름은 {type}/{설명} 형식으로 짓는다.
  2. {type}은 커밋 타입(feat|fix|docs|style|refactor|test|chore)과 의미가 대응하되, feat만 feature로 풀어 쓴다: feature/fix/docs/style/refactor/test/chore.
  3. {설명}은 소문자 케밥 케이스로 작성한다(예- feature/guest-login, docs/branch-guide).

커밋 메시지 형식

Section titled “커밋 메시지 형식”
  1. Conventional Commits 형식(type(scope): subject)을 따르며, commitlint로 검증한다.
  2. 제목은 50자 이내로 작성한다.
  3. 서로 다른 관심사(기능 추가/버그 수정/문서 정리 등)는 하나의 커밋에 섞지 않고 목적 단위로 분리해서 커밋한다.

브랜치 역할과 병합 규칙

Section titled “브랜치 역할과 병합 규칙”

master

평소 작업이 쌓이는 통합 브랜치. 더 이상 배포를 트리거하지 않는다.

작업 브랜치

기능 추가/버그 수정/문서 작성 등 목적이 있는 모든 작업은 master에서 분기해서 진행한 뒤 master로 병합하고, 병합 후에는 삭제한다.

deploy

실제 배포를 트리거하는 브랜치. master에 쌓인 변경을 배포하고 싶은 시점에 사람이 직접 master를 deploy로 병합·푸시한다.

  1. 병합은 항상 **git merge --no-ff**로 실행한다(fast-forward 금지). git rebase는 사용하지 않는다.
  2. 작업 브랜치는 오직 master로만 병합할 수 있다. deploy를 포함해 다른 브랜치로 직접 병합하는 것은 금지한다.
  3. master에 변경이 반영되는 경로는 (1) 작업 브랜치의 --no-ff 병합, (2) PR 병합 이 둘뿐이다. master에 체크아웃한 채 직접 커밋/cherry-pick/revert/rebase하는 것은 금지한다.
  4. 작업 브랜치를 master에 병합한 뒤에는 그 자리에서 바로 작업 브랜치를 삭제한다.
  5. “커밋해줘”와 “병합해줘”는 별개의 요청이다. 커밋 요청만으로는 master(또는 deploy)로 병합하지 않으며, 병합은 별도로 요청받았을 때만 진행한다.