개발 규칙

User Story

• who - 프로젝트 참여자들
• what - 개발규칙을 따른다.
• how - 하단의 내용들을

branch 전략

• git flow를 따른다

branch naming

• issue number-issue name
• ex) 16-defining-development-rules

commit message

• [#issue number>] [behavior(upper case)] message
• ex. [#16] [FIX] 개발 규칙 오타 수정
• behavior type(참고 - Contributing to Angular)
  • BUG - 버그 수정
  • FIX - 개선 및 수정
  • FEAT - 기능 개발
  • DELETE - 의존성, 코드, 패키지 등 삭제
  • MODIFY - 일반적인 수정
  • HOTFIX - 운영 상황일때 급할 경우
  • DOCS - Readme 파일 수정 시
  • TEST - 테스트 코드 작성

개발 프로세스

1. issue 생성

• 1-1. issue 생성

  

• 1-2. issue Template 선택

  

• 1-3. issue Teplate에 맞게 issue 내용 작성 - 제목, 이슈 설명, 완료 조건 추가, 관련 이슈 및 레퍼런스(있을 경우에만 추가)

  

2. issue 기반 branch 생성(Git Flow 방식으로 브랜치를 초기에 셋팅)

• 2-1. issue와 관련된 부모 branch로 이동하여 branch를 생성(develop, [issueNumber]-parents-branch등으로 branch 이동)

  

• 2-2. issue의 번호와 이름으로 branch명 작성

  

3. issue와 관련된 feature 개발 완료

• 3-1. 개발 완료

  • 커밋 메시지 - ex.[#16] [FIX] 개발 규칙 오타 수정
  • 해당 feature에대한 Test Code 필수

  

• 3-2. origin feature에 push(upstream - organization repository, origin - fork repository)

  

4. merge commit 생성시(PR) commit message rule에 맞춰서 squash merge를 위해 commit history 단장

• 4-1. PR 생성

  

• 4-2. PR 작성

  

5. PR merge

• 5-1. PR이 주요 branch로 merge되기 위한 조건

  • 최소 1명의 review의 approve
  • CI로 인한 build success

  

• 5-2. 상황에 맞게 merge 전략 선택

  • Squash and merge : develop - feature 브렌치간 머지

    

  • Squash and merge : develop - feature 브렌치간 머지

    

  • Create a merge commit merge : hotfix - develop, hotfix - master 브렌치간 머지

    

6. merge 후 feature branch 제거

7. issue close

Reference

• Udacity Git Commit Message Style Guide