깃허브 컨벤션

🌲 모모 브랜치 전략 : git-flow

branch	사용 목적
main	서비스을 직접 배포하는 역할을 하는 브랜치
develop	feat에서 개발된 내용을 가지고 있는 브랜치
feat	각 기능 별 개발 브랜치. 리팩터링이나 수정사항을 반영한 내용도 해당 브랜치 사용.
hotfix	main 브랜치로 배포를 하고 나서 버그가 생겼을 때 빨리 고치기 위한 브랜치
release	배포를 하기 전 내용을 QA(품질 검사)하기 위한 브랜치

• release branch는 당장 사용하지 않는다.
  • 차후 실사용자가 추가되어 운영 서버/ 개발 서버 분리가 필요해질 시 추가 여부를 논의할 예정

git-flow 전략을 사용한 이유

• 이미 경험한 팀원들이 많기 때문에 익숙하게 사용할 수 있다.
• git-flow에 관련되어 참고할 수 있는 레퍼런스가 많다.

merge 전략

• 상황 1 : feat/#{something} ⇒ develop
  • squash and merge
  • feat 브랜치는 develop 브랜치 병합 후에 제거한다. 때문에 merge commit을 남길 필요가 없다. 또한 지저분한 커밋 내역을 다 표시할 필요가 없다.
• 상황 2 : develop ⇒ main
  • rebase and merge
  • main은 기능 배포할 때 사용하는 브랜치이다. 따라서 커밋 이력을 남겨두고 문제가 생겼을 때 기능 별로 롤백할 수 있도록 한다.
  • develop → main 은 하나의 점으로 통합하여 버전을 표시하려 한다.

🌱 커밋 컨벤션

type	설명
feat	새로운 기능 추가
refactor	코드 리팩터링
fix	버그, 오류 수정
test	테스트 코드 추가, 수정
docs	문서 작성, 수정
chore	패키지 매니저 업데이트 ex) .gitignore, package.json 관련
design	디자인(css, layout)추가, 변경
style	코드 스타일 변경
!hotfix	급하게 치명적인 버그를 고쳐야하는 경우
build	빌드 관련 추가, 수정
rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
remove	파일을 삭제하는 작업만 수행한 경우
comment	주석 추가 및 수정
release	버전 릴리즈