코딩컨벤션 | Notion

1. 깃 컨밴션

1-1. 커밋 유형 지정

커밋 유형	의미
`feat`	새로운 기능을 추가할 때 사용합니다. 예를 들어, 새로운 API 엔드포인트를 추가하거나 사용자 인터페이스에 새로운 버튼을 추가하는 경우입니다.
`fix`	기존 코드의 버그를 수정할 때 사용합니다. 예를 들어, 함수의 잘못된 로직을 고치거나, 잘못된 변수 값을 수정하는 경우입니다.
`docs`	문서 파일을 수정할 때 사용합니다. 예를 들어, README 파일을 업데이트하거나, 주석을 추가하는 경우입니다.
`style`	코드의 스타일만 변경할 때 사용합니다. 예를 들어, 들여쓰기를 맞추거나, 세미콜론을 추가하는 경우입니다. 코드의 동작에는 영향을 미치지 않습니다.
`refactor`	기능의 변경 없이 코드 구조를 재정비할 때 사용합니다. 예를 들어, 함수나 변수의 이름을 더 의미 있게 바꾸거나, 복잡한 로직을 단순화하는 경우입니다.
`test`	테스트 코드를 추가하거나 기존 테스트 코드를 리팩토링할 때 사용합니다. 예를 들어, 새로운 테스트 케이스를 추가하거나, 테스트 스크립트를 수정하는 경우입니다.
`chore`	패키지 매니저 설정이나 그 외 기타 작업을 할 때 사용합니다. 예를 들어, .gitignore 파일을 수정하거나, 빌드 스크립트를 변경하는 경우입니다.
`design`	CSS 등 사용자 인터페이스 디자인을 변경할 때 사용합니다. 예를 들어, 버튼의 색상을 변경하거나, 레이아웃을 수정하는 경우입니다.
`comment`	코드에 주석을 추가하거나 기존 주석을 수정할 때 사용합니다. 예를 들어, 코드의 특정 부분을 설명하는 주석을 추가하는 경우입니다.
`rename`	파일이나 폴더의 이름을 변경하거나 위치를 옮길 때 사용합니다. 예를 들어, 파일의 이름을 더 의미 있게 바꾸거나, 디렉토리 구조를 재정비하는 경우입니다.
`remove`	파일이나 폴더를 삭제할 때 사용합니다. 예를 들어, 더 이상 필요 없는 코드를 삭제하는 경우입니다.
`!BREAKING CHANGE`	호환성이 깨지는 커다란 변경 사항을 도입할 때 사용합니다. 예를 들어, API의 인터페이스를 변경하거나, 주요 기능을 대대적으로 수정하는 경우입니다.
`!HOTFIX`	치명적인 버그를 긴급히 수정할 때 사용합니다. 예를 들어, 서비스 장애를 일으키는 버그를 빠르게 고치는 경우입니다.
`init`	프로젝트 초기 설정을 할 때 사용합니다. 예를 들어, 초기 폴더 구조를 생성하거나, 초기 설정 파일을 추가하는 경우입니다.

1-2. 브랜치 관리 전략

main

항상 Stable한 상태
- Stable하다는 것: 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과 해야 한다.
develop

다음 버전 개발을 위한 브랜치, 개발이 완료되면 main으로 머지한다.
feature

기능 개발에 필요한 브랜치, develop 브랜치에서 생성하고 기능 개발이 완료 되면 develop으로 머지한다.
```
feature/(기능명)

ex) feature/loginForm 
ex) feature/loginFix
```

*보통은 hotfix, release 브랜치를 사용하기도 하는데, 웹 애플리케이션에 적합하지 않을 수 있고 프로젝트 규모에 비해 브랜치 전략이 너무 복잡해 질 수 있으므로 상의를 통해 결정한다.

참고

2. 코딩컨벤션

모든 네이밍은 모든 팀원이 이해하기 편하면서 심플하게 작성한다.

2-1 디렉토리 및 파일 컨벤션

디렉토리 명 : camelCase
일반 파일명 : camelCase
컴포넌트 파일명 : PascalCase