태스크 관리 (이 부분은 Jira 사용.)
- 우선 유저 스토리가 어느 정도 정리되어서 나온다면, 태스크를 적절한 단위로 분할하여 Github 레포지토리에 Issue 를 작성합니다. (Issue 관리자? 태스크 관리자? 담당)
- 일간 혹은 주간 단위의 태스크가 어느 정도 나왔으면, 의존성으로 인한 병목이 없는 기능부터 각자가 자신의 태스크를 골라서 작업하려는 Issue 페이지에서 자신이 작업할 것임을 코멘트로 남깁니다. (다른 팀원과의 중복 작업 방지)
- 자신이 작업할
feature/*브랜치를 만들어서 작업을 진행합니다.
- 작업 완료 후
develop브랜치로 머지가 완료된feature/*브랜치는 제거합니다.
Git 브랜치 전략
- main: 메인 브랜치
- hotfix: 급한 수정이 필요할 때 사용하는 브랜치
- release: 배포 브랜치
- develop: 개발 통합 브랜치 (각종 feature가 머지되는 곳)
- feature/*: 단위 기능 개발 브랜치 서비스 기능 구현, 버그 수정, 리팩토링, 문서화 등등 단일 태스크에 대한 작업이라면 모두 여기에 해당합니다. 개발 완료후 develop 브랜치로 머지가 된 feature 브랜치는 제거합니다. 또한 feature의 뒤에는 이슈 번호를 입력합니다. ex) #15번 이슈에 대한 기능을 작업중이라면 feature/15
커밋 메시지 규칙
Type | 설명 |
feat: | 새로운 기능 추가
(기능을 수정했는데 사용자가 보는 화면이 달라지면 여기에 해당.
단, 버그 수정이라면 fix 타입 사용) |
fix: | 버그 수정 또는 typo |
refactor: | 리팩토링
(기능을 수정했는데 사용자가 보는 화면은 똑같으면 여기에 해당.) |
design: | CSS 등 사용자 UI 디자인 변경 |
comment: | 필요한 주석 추가 및 변경 |
style: | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
test: | 테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우) |
chore: | 위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등) |
init: | 프로젝트 초기 생성 |
rename: | 파일 혹은 폴더명 수정하거나 옮기는 경우 |
remove: | 파일을 삭제하는 작업만 수행하는 경우 |
docs: | 문서 작업
커밋 메시지 헤더의 접두어로는 작업의 형태마다 위 타입을 작성합니다. |
작업 형태에 따라서 커밋 메시지 헤더의 접두어로 위 테이블에 존재하는 타입을 작성합니다.
만약 작업한 내용이 위 타입 중에서도 어느 것에 속하지 않는 애매한 경우가 존재한다면 추후에 의논해서 추가하거나 수정합니다.
작성 예시
feat: 사용자 로그인 페이지 작성
fix: useScroller의 스크롤 정보가 새로고침시 초기화되는 현상 수정