리뷰
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 브랜치에서 발생한 버그를 수정하는 브랜치입니다.
•
refactor: 리팩토링을 진행할 때 사용하는 브랜치입니다.
◦
예시) refactor/login
•
위 브랜치 중 항시 유지되는 브랜치는 master, develop 브랜치이며 merge 되면 사라지는(삭제하는) 보조 브랜치는 feature, release, hotifx, fix, refactor 5가지로 구성됩니다.
Commit Convention
•
commit-tag(Domain): commit message (#issue)
◦
작업 타입 | 이모지+타입 | 작업내용 |
:sparkles: feat | 해당 파일에 새로운 기능이 생김 | |
:tada: create | 없던 파일을 생성함, 초기 세팅 | |
:recycle: refactor | 코드 리팩토링 | |
:bug: fix | 코드 수정 | |
:ambulance: HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 | |
:pushpin: chore | 빌드 업무 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 | |
:truck: rename | 파일 옮김/정리, 파일명 변경 | |
:fire: remove | 기능/파일을 삭제 | |
:white_check_mark: test | 테스트 코드를 작성 | |
:lipstick: style | css | |
:speech_balloon: docs | md 파일, 문서 작업 | |
:bulb: comment | 필요한 주석 추가 및 변경 | |
:see_no_evil: gitfix | gitignore 수정 | |
:twisted_rightwards_arrows: gitmerge | 브랜치 합병 | |
:rewind: gitrevert | 변경 내용 되돌리기 |
깃모지