Git

커밋 규칙

<타입> <제목>

<내용>

타입

• ✨ - 새로운 기능 추가
• 🐛 - 버그 픽스
• ♻️ - 리팩터링
• 📝 - 문서 추가/수정
• 🚚 - 리소스 이동 또는 이름 변경
• 🔧 - 설정 파일 추가/수정

그 밖에 다른 타입이 필요한 경우 gitmoji를 참고해 목록에 추가 바랍니다.

브랜치 전략

github-flow

• 배포가 필요없는 사이드프로젝트이기 때문에 가장 단순한 전략을 사용합니다.

• release 브랜치 없이 하나의 버전이 만들어졌으면 배포될 수 있다는 개념으로 hotfix가 사소한 기능 변화라고 생각합니다.

  • master: 안정적인 코드가 저장되는 브랜치로 여기서부터 새로운 브랜치가 생성됩니다. 항상 stable하며 production에 배포되는 브랜치입니다.
  • feature branches: 각 기능이 개발되는 브랜치로, master 브랜치에서 파생되고 완료되면 다시 병합됩니다. Pull Request를 통해 코드 리뷰가 이루어집니다.

• git-flow와 달리 브랜치별 구분이 없기 때문에 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해야합니다.

  

프로젝트

패키지 구조

이 아키텍처는 '만들면서 배우는 클린 아키텍처'에서 제안된 표현력 있는 패키지 구조를 기반으로 합니다. 그러나 애플리케이션의 규모를 고려할 때, 여러 인커밍 어댑터가 필요할 가능성이 낮습니다. 이는 인커밍 포트 없이도 프로세스 흐름을 쉽게 이해할 수 있음을 의미합니다. 따라서, 불필요한 추상화 계층을 제거하기 위해 인커밍 포트를 사용하지 않기로 결정했습니다.