1. 공통

Git Commit 컨벤션

feat: 새로운 기능을 추가할 경우
fix: 버그를 고친 경우
style: 코드 포맷 변경, 간단한 수정, 코드 변경이 없는 경우
refactor: 코드 리팩토링
docs: 문서를 수정한 경우(ex> Swagger)
chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우
rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
remove: 파일을 삭제하는 작업만 수행한 경우

Git Flow 브랜치 전략

• 사용 브랜치
  • main
    • 배포 가능한 상태의 결과물 올리는 브랜치
  • develop
    • 구현 완료된 기능을 병합하기 위한 브랜치
  • feature
    • 개별 기능 구현 브랜치
    • 기능 개발 완료 시 삭제
    • 네이밍 규칙(소문자)
      • feature/기능이름
      • 예) feature/login
• 진행 방식
  • feature의 기능이 완성되면 develop에 PR을 통해 merge
  • 배포 준비가 완료되면 develop 브랜치를 main에 merge

2. 프론트엔드

Rebase Merge로 진행

• 기존 방식보다 브랜치를 깔끔하게 관리할 수 있다.

  • merge commit이 남지 않는다.

• develop → main으로 머지할 경우는 rebase가 아닌 merge commit으로 진행

  • release 과정에서 문제가 발생할 경우, merge commit으로 어떤 시점의 develop 브랜치가 main에 머지되었는지 확인 가능
  • 히스토리 관리 및 배포와 관련된 이슈 트래킹에 유리하다.

• 관련 링크

  https://velog.io/@mohai2618/Git-Merge-종류

코드 리뷰 Pn 룰 적용

• 관련 링크 : https://blog.banksalad.com/tech/banksalad-code-review-culture/

- **P1**: 꼭 반영해주세요
- **P2**: 적극적으로 고려해주세요
- **P3**: 웬만하면 반영해 주세요
- **P4**: 반영해도 좋고 넘어가도 좋습니다
- **P5**: 그냥 사소한 의견입니다