리뷰

• template

PR

• 다음 브랜치로 이동할 경우 반드시 pull request를 통해 이동한다.
• 절대로 master 브랜치로 바로 merge 및 push 하지 않는다.
• template

Issue

• 이슈 내부에서 체크박스로 관리
• template

Label

• commit type 기준으로 커스텀

Branch Convention

• master: 라이브 서버에 제품으로 출시되는 브랜치.
  • (주의) 절대 바로 master 브랜치에 push 하지 마세요. 반드시 팀원들과 협의 후 pull request를 통해 master 브랜치로 merge합니다.
• develop: 다음 출시 버전을 대비하여 개발하는 브랜치.
  • feature 브랜치에서 팀원과 협의후 완성된 기능인 경우 pull request를 통해 develop 브랜치로 merge 합니다.
• feat: 기능 개발 브랜치로 기능 완성 시 develop 브랜치로 pull request로 merge 합니다.
  • feat/기능요약
  • 예시)
    • feat/login
    • 띄어쓰기가 필요할 경우 대시(-)를 사용: feat/login-something
• fix: feature 또는 develop 단계의 브랜치에서 발생한 버그를 수정하는 브랜치
  • 예시)
    • fix/login-bug
• release: 다음 버전 출시를 준비하는 브랜치
  • develop 브랜치를 release 브랜치로 pull request로 merge 후 최종 테스트 이후 master 브랜치로 merge합니다.
  • 예시) release/1.0.0
  • 깃헙 릴리즈(releases) 작성
    • develop 에서 테스트가 완료 후 master 브랜치로 merge되면 릴리즈를 작성합니다.
    • 메이저 버전 증가: 1.0.0 → 2.0.0
      • 대대적인 변화가 일어났을 경우
    • 마이너 버전 증가: 1.0.0 → 1.1.0
      • 새로운 기능이 추가 될 때
      • 기존 기능이 변경되거나 사용 방법이 변경 되었을 때
    • 패치 버전 증가: 1.0.0 → 1.0.1
      • 버그 수정
      • 기존 클라이언트가 알아차리지 못할 정도의 작은 변화가 있을 때
      • 서버 코드 내부적으로 소스가 수정되었을 떄(리팩토링)
• hotfix: master 브랜치에서 발생한 버그를 수정하는 브랜치입니다.