컨벤션

🗳 Github 브랜치 전략

Git Flow

1. 각 용도에 맞게 main(master), develop, feature, release, hotfix 브랜치를 분리해서 사용
2. 명확한 릴리즈 기간과 주기적인 버전이 정해진 프로덕트를 개발하는 환경에 적합
3. 릴리즈 버전 관리를 위한 release 브랜치를 따로 관리하기 때문에, 특정 버전에 대한 유지보수 기간이 길고, 여러 버전을 동시에 관리해야 할 필요가 있을때 유용함

관리 할 브랜치가 많아지고 해당 프로젝트가 이정도의 규모가 아니라 탈락

GitHub Flow 🥇

1. Git Flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략
2. hotfix 브랜치나 feature 브랜치를 구분하지 않음
3. 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용

Git Flow만큼 복잡하지 않으면서 TBD처럼 너무 간단하지 않아서 선정

TBD

1. 기본적으로 Trunk/Main 브랜치 하나만 사용
2. 신규 피쳐의 경우 main에 커밋하거나, 수일 내로 머지 할 브랜치를 생성
3. PR을 생성하지 않음

PR을 생성한다고 하면 GitHub Flow와 다를게 없고 없앤다고 하면 추적이 힘들어져 탈락

🏷 Github 브랜치 네이밍 컨벤션

1. 기능 추가: feature/기능명

• ex) feature/login, feature/add-product

2. 버그 수정: fix/버그명

• ex) fix/login-err

3. 리팩토링:refactor/리팩토링명

• ex) refactor/login-ui

4. 문서:docs/문서명

• ex) docs/readme

🔒 브랜치 보호 룰 (Default Branch = main)

• Require a pull request before merging

  • main브랜치로의 병합은 반드시 PR을 거쳐야함.
  • 1명 이상에게 승인을 받아야 병합이 가능함.

• Require status checks to pass before merging

  • 병합되기 전에 반드시 Github Actions 테스트 스크립트가 문제없이 성공한 상태여야 함.

• Require conversation resolution before merging

  • 모든 conversation은 resolved 처리 되어있어야함.

• Do not allow bypassing the above settings

  • Admin 권한을 가진 사용자도 위의 규칙들을 준수해야함.

💾 커밋 컨벤션

접두사	설명	예시
✨ feat	새로운 기능을 추가할 때 사용	✨ feat: 유저 프로필 기능 추가
🐛 fix	기존 버그를 수정할 때 사용	🐛 fix: 로그인 오류 해결
♻️ refactor	코드 구조를 개선할 때 사용	♻️ refactor: API 호출 로직 정리
⚡️ perf	성능을 향상시킬 때 사용	⚡️ perf: DB 쿼리 최적화
💄 style	UI/UX 스타일 변경 시 사용	💄 style: 버튼 색상 변경
📝 docs	문서를 추가하거나 수정할 때 사용	📝 docs: README 업데이트
✅ test	테스트 코드를 추가/수정할 때 사용	✅ test: 유닛 테스트 추가
📦 chore	패키지 관리, 빌드 관련 작업 시 사용	📦 chore: 라이브러리 버전 업데이트
🧼 clean	필요없는 코드 제거, 이름 변경 시 사용	🧼 clean: import문 제거