ABCDEdu-frontend

🔴 GitHub-flow 정책

• 브랜치는 꼭 develop를 기반으로 생성하여 작업을 진행한다.
• 브랜치 변경 후 로컬에 commit하고, 정기적으로 원격 저장소에 push 한다.
• Merge 전에, develop를 기준으로 pull 하여 충돌 난 곳이 있는지 확인한다.
• 기능 완성 후 코드 병합할 준비가 되었다면 Pull request를 만든다.

🌟 잘 이용하기 위한 약속

• 커밋 메시지를 명확하게 작성

• 커밋 전 반드시 husky를 통해 lint-staged를 실행한다.

  • 자동 실행이 불가능하다면 npm run lint && npm run format:fix 실행

• 원격 브랜치로 수시로 push 하자 (develop에 하라는 얘기가 아님, 기록용 Push)

• 브랜치 이름은 자세하게 - 어떤 일을 하고 있는지에 대해서 작성

이름	설명
main	배포 대상 (production)
develop	테스트
feature	새 기능 추가가 목적인 브랜치
bug	버그 수정이 목적인 브랜치
test	무언가를 테스트하는 브랜치 (새 라이브러리, 배포 환경, 실험 등)

🔼 해당 카테고리를 접두어 + 중분류(기능명 등) // + 본인 이름 약자

(만약, 기능 구현을 다 하지 못 했는데 중간에 Merge를 하게 되면, 브랜치명 뒤에 숫자를 넣어서 버전을 구분해 준다.)

예시 : feat/post/csj , feat/post-2/csj

feature —-(pr,merge)——> develop → main

💬 Commit 컨벤션

• message에 들어가야 사는 내용
  • 왜 커밋했는지 설명
  • 버그 수정의 경우, 어떤 문제가 있었는지 설명
  • 이슈 번호
    e.g. feat: 포스트 기능 구현 #1

커밋 타입	설명
build	- 처음 초기 세팅을 할 때 사용합니다. - 시스템 또는 외부 dependency에 영향을 미치는 변경 사항이 있을 경우 사용합니다. - package.json, cicd.yml
feat	새로운 기능을 추가/수정/삭제할 때 사용합니다.
fix	버그 수정 시 사용합니다.
refactor	리팩토링 시 사용합니다. 코드의 기능 변경이 아닌 재사용성 향상, 성능 개선, 주석 추가 등
rename	파일, 폴더 이름 변경 또는 이동할 때 사용합니다.
test	테스트 코드를 작성 또는 수정할 때 사용합니다.
docs	문서 (주석) 관련 작업을 할 때 사용합니다. (README.md, .github, …)
chore	폴더나 전체적인 구조 설정을 할 경우 사용합니다.
style	코드 의미에 영향을 주지 않는 변경 사항을 추가할 때 사용, 가독성 관련 (e.g. 줄 바꿈)