개발 문화
- fork로 분기 작업
- main: deploy를 위한 브랜치 (배포시 dev브랜치에서 최종적으로 로컬로 테스트 해보고 배포)
- dev: 개발이 시작되는 branch. feature/개발기능에서 작업이 끝난경우 PR을 dev로 보낸다
- feature branch
- feature/{issue-number}-{feature-name}
- ex)feature/1-초기-세팅
- PR의 목적을 한 문장으로 요약하기
- PR을 생성하게된 맥락이 있는데 이를 리뷰어가 알아야 한다면 함께 명시
- 요청한 PR이 작업중이라면 'WIP(Work In Progress)' 라고 기재
- 원하는 피드백에 관해 명확히 표현
- 피드백에 대한 감사의 표현 + 최대한 모든 내역에 대해 응답
- 이해가 안됐을 경우 적극 표현하기
- 혼란, 논쟁이 증가하고 있다면 PR 문서 검토
- 코드리뷰 필수 (만약 급하게 PR 머지가 필요한 경우 제외)
- merge는 최소 한명에게 리뷰를 받고 상의가 되면 merge 한다.
- commit 내역을 보고 PR 문서를 작성한다.
- title은 브랜치 방향을 명시하도록 작성
- ex : Feature/2 initial setting -> dev : PR 내용 한 문장
ex) #{이슈번호} feat({클래스/패키지명/*}): 커밋메세지
add: 새로운 코드를 추가할 경우
update: 코드를 고친 경우
feat: 새로운 기능을 추가할 경우
fix: 버그를 고친 경우
design: CSS 등 사용자 UI 디자인 변경
breaking change: 커다란 API 변경의 경우
hotfix: 급하게 치명적인 버그를 고쳐야하는 경우
style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
refactor: 프로덕션 코드 리팩토링
comment: 필요한 주석 추가 및 변경
docs: 문서를 수정한 경우
test: 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
remove: 파일을 삭제하는 작업만 수행한 경우
- 변수, 함수, 인스턴스명: 카멜케이스
- 함수명: 동사+명사
- Boolean 변수명: 조동사+flag 종류. ex) isNum, hasNum
- 디자인패턴: 싱글톤
- tab의 최대 depth는 4로 제한
- 깃허브 커밋 컨벤션을 지킨다.
- 함수에 대한 주석
://www.erdcloud.com/d/DccZvwQjyWZyva7nq