브랜치 전략

참고 : TeamCARDNA의 How to use Git

1. 기본

1.1 GitHub Branch 협업 프로세스

1. '원본 remote repository'(upstream&organization)를 깃허브에서 fork
2. 'fork한 remote repository'(origin)를 깃 클라이언트로 clone
3. 'clone한 repository'(local)에 commit
4. local에서 origin으로 push
5. upstream에 반영
   6-1)PR을 등록하기 전 upstream에 바뀐 내용이 없는 경우
   -> origin에서 upstream으로 PR(Pull Request)
   6-2)PR을 등록하기 전 upstream에 바뀐 내용이 있는 경우
   -> upstream을 local로 pull -> local에서 origin으로 push -> origin에서 upstream으로 PR(Pull Request)

2. Branch Naming Rule

2.1 Branch 작업 단위

• Branch는 가능한 한 작업단위, 기능단위로 생성하며 이는 Issue를 기반으로 한다.
• 단, 같은 범위의 기능이라면 같은 브랜치를 사용한다.
• 예를 들면, 회원가입 기능 구현 시 아이디 중복 체크, 비밀번호 확인, 아이디 유효성 확인 등은 회원가입 하나로 구분한다.

2.2 Branch의 이름

• Branch를 생성하기 전 Issue를 먼저 작성한다.
• Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch의 이름을 결정한다.
• <Prefix>/<Issue_Number>-<Description> 의 양식을 따른다.

3. Prefix

• main : 개발이 완료된 산출물이 저장될 공간
• develop : feature 브랜치에서 구현된 기능들이 merge될 브랜치(안정화)
• feature : 기능을 개발하는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다
• release : 릴리즈를 준비하는 브랜치, 릴리즈 직전 QA 기간에 사용한다 (스토어)
• hotfix : 버그를 수정하는 브랜치