1. Commit
Feat | 새로운 기능을 추가(수정)할 경우 | Feat: 회원가입 폼 추가
Feat: 로그인 버튼 수정 |
Fix | 버그를 고친 경우 | ㅤ |
Style | 코드 포맷 변경(오타 수정, 탭 사이즈 변경, 변수명 변경), 세미 콜론 누락, 코드로직 수정이 없는 경우 | ㅤ |
Design | CSS등 사용자 UI 디자인 변경 | ㅤ |
Comment | 필요한 주석 추가/삭제/수정한 경우 | ㅤ |
Rename | 파일 혹은 폴더명을 수정하거나 옮기는 경우 | ㅤ |
Refactor | 프로덕션 코드 리팩토링 | ㅤ |
Chore | 빌드 태스크 업데이트, 패키지 매니저 설정 (실제 production 코드 변경은 없음)
ex. package.json 변경, 그외 자잘한 것 | ㅤ |
!HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 | ㅤ |
2. Branch
# 브랜치 전략 참고자료 링크 > 참고로 release 브랜치는 뺐습니다. 소규모 프로젝트에선 오히려 복잡도만 높일 것 같습니다. ## 브랜치 종류 ### main - 최상위 브랜치 - 완성되어 테스트가 끝난 develop 브랜치의 코드를 병합 ### develop - 개발된 기능을 다른 사람들 코드와 병합 - 필연적으로 충돌 발생 - 충돌은 개인 로컬 브랜치에서 전부 해결하고 푸시해야됨 - 충돌 해결 후 테스트 필수 ### feature - 실질적으로 기능을 개발하는 브랜치 - 개발 완료된 기능은 우선 해당 feature 브랜치에 푸시하고 develop으로 PR 작성 - 리뷰어의 요청사항을 로컬에서 수정 후 푸시 - develop으로 merge가 완료된 feature 브랜치는 삭제 ### hotfix - develop이나 main에서 버그, 에러 발생시 수정을 위한 브랜치 - 버그나 에러에 대한 내용을 담은 이슈 생성 - 해당 이슈 번호로 네이밍 <br> ## 브랜치 네이밍 규칙 ### main, develop - 이름 그대로 사용 ### feature - `feature/{기능명}` - 기능명 : kebab-case ex) feature/landing-page > 애매한 경우 회의에서 결정 ### hotfix - `hotfix/{이슈번호}` - 버그에 대한 이슈 생성 후 이슈번호로 브랜치 이름 작성 ex) hotfix/13
3. Pull Request
- PR 템플릿에 맞춰서 작성해요.
- PR 제목은
브랜치명 : PR에 대한 간단한 요약으로 작성해요.
- 리뷰이는 리뷰어를 배려해 최대한 자세히 상세히 열심히 작성해요.
4. Merge
- PR을 올린 사람이 리뷰를 받은 후 직접 Merge해요
- 2명 이상에게 리뷰를 받았을 경우에 Merge가 가능해요