브랜치 규칙

브랜치를 관리하는 규칙들을 정리하고 있어요.

브랜치를 관리하는 방법은 프로젝트마다 다를 수 있어요, 하지만 기본적인 큰 틀은 위 규칙을 따라주세요.

브랜치 구성

plaintext

main (production)
  ↑
develop (staging)
  ↑
feature/*  (기능 개발)
hotfix/*   (긴급 수정)
release/*  (릴리즈 준비)

브랜치들의 기본 구성은 이렇게 되어있어요.

브랜치명	설명	부가설명
main	실제 프로덕션 서버가 추구해야 할 코드들을 가지고 있어요.
develop	프로덕션을 하기 전 내부 개발 단계의 코드들을 가지고 있어요.	기여자가 1~2명 정도인 작은 프로젝트에서는 develop 를 생략해도 좋아요. 하지만 프로젝트가 커지게 되면 develop 브랜치를 추가해야해요.
feature	기능 개발을 하고 있는 코드들을 가지고 있어요.
fix	기능 오류 수정 중인 코드들을 가지고 있어요.
refactor	기능 수정 중인 코드들을 가지고 있어요.
hotfix	긴급한 오류를 해결하기 위한 코드들을 가지고 있어요.	hotfix는 예외적으로 main, develop 모두 pull_request를 생성할 수 있어요.
release	제품 릴리즈를 위한 코드들을 가지고 있어요.	제품 릴리즈를 하기 위한 목적으로, 필요한 프로젝트만 선택해서 사용할 수 있어요.

main, develop 과 같은 특수한 브랜치를 제외하고서는 모든 브랜치는 하나의 issue를 1:1로 가지고 있어야해요.

기본적인 브랜치 형식은 다음과 같아요.

Terminal

$ <branchname>/#<number>-<subject>

branchname은 뭘 하는 브랜치인가? 를 정의하는 예약어에요.

위에 설명된 브랜치명을 사용하면 돼요.

number는 연결되는 다른 링크의 번호가 무엇인가?를 나타내는 숫자에요.

number에는 해당 브랜치에 해당하는 issue 번호를 작성해야해요. (이때 숫자 앞에 #는 꼭 붙여야 해요.)

release브랜치를 사용하고 있다면, number앞에 #대신 v를 사용해야해요.

subject는 이 브랜치가 할일이 무엇인가? 를 정의하는 문장이에요.

subject를 작성하는데는 다음과 같은 규칙을 꼭 지켜야 해요.

브랜치 형식의 좋은 예시는 다음과 같아요.

plaintext

feature/#123-webview-camera-bridge
feature/#456-push-notification-system
hotfix/#789-login-token-refresh
release/v2.0.0

브랜치 형식의 나쁜 예시는 다음과 같아요.

plaintext

Feature/#123-test → 구체적이지 않음, 대문자 사용
feature/345-background-worker-thread → 숫자 앞에 # 미포함
release/#2.0.0 → release임에도 # 사용