Skip to content

브랜치 전략

DaBin edited this page Jan 26, 2022 · 5 revisions

참고 : TeamCARDNA의 How to use Git

1. 기본

1.1 GitHub 협업 프로세스

  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 Naming Rule

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

2.2 Branch의 이름

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

3. Prefix

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