///
Search
Duplicate

Github Convention

리뷰

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)
feat(User): user api 작성 (#2)
작업 타입
이모지+타입
작업내용
 feat
:sparkles: feat
해당 파일에 새로운 기능이 생김
 create
:tada: create
없던 파일을 생성함, 초기 세팅
 refactor
:recycle: refactor
코드 리팩토링
 fix
:bug: fix
코드 수정
 HOTFIX
:ambulance: HOTFIX
급하게 치명적인 버그를 고쳐야하는 경우
 chore
:pushpin: chore
빌드 업무 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음
 rename
:truck: rename
파일 옮김/정리, 파일명 변경
 remove
:fire: remove
기능/파일을 삭제
 test
:white_check_mark: test
테스트 코드를 작성
 style
:lipstick: style
css
 docs
:speech_balloon: docs
md 파일, 문서 작업
 comment
:bulb: comment
필요한 주석 추가 및 변경
 gitfix
:see_no_evil: gitfix
gitignore 수정
 gitmerge
:twisted_rightwards_arrows: gitmerge
브랜치 합병
 gitrevert
:rewind: gitrevert
변경 내용 되돌리기
깃모지