1. Github
- 기능별로 Issue 파기 ( feat, fix, refactor, etc)
이슈제목은 [ 페이지명 ] - 기능명 으로 하실게요~
- 작업할 이슈에 대해 Label & assign 꼭 달아주세요!
- 꼭 커밋 단위를 ‘쪼개서' 올려주세요!!🔥🔥
- 작업 다 하면 PR 올리고 웹파트원 리뷰어 등록 & Label 달아놓기 & PR 템플릿에 맞게 작업내용 기록해두기
- PR 제목은 브랜치명으로 할게요~~
2. Commit Convention
| [ feat ] |
새로운 기능이 추가되었을 때 ex. [ feat ] 마이페이지 구현 |
| [ fix ] |
버그를 고친 경우 |
| [ design ] |
css 혹은 UI를 생성 & 변경한 경우 |
| [ style ] |
코드포맷 변경 (기능에 변화가 없는 경우) |
| [ refactor ] |
더 좋은 코드로 개선한 경우 ( 기능에 변화가 없는 경우) ex) 코드리뷰 반영 |
| [ docs ] |
readMe 등 문서를 추가한 경우 |
| [ test ] |
테스트코드 작성 |
| [ etc ] |
이 외 잡일들~ |
3. 브랜치 전략
Git-Flow
git-flow에는 5가지 브랜치가 존재
- main : 기준이 되는 브랜치로 제품을 배포하는 브랜치
- develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
- feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
- release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
- hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치
<aside>
💡 git-flow의 과정
- main 브랜치에서 develop 브랜치를 분기합니다.
- 개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
- 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기합니다.
- 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
- 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
- 테스트가 완료되면 release 브랜치를 main와 develop에 merge합니다.
</aside>
*이번 합세는 규모가 엄청 큰 프로젝트는 아니라고 생각하여 develop브랜치를 따로 만들지 않고, main 브랜치를 메인으로 하겠습니다!
브랜치명