README.md

Backend

큐시즘 28기 해커톤 F팀 "텀블러 키우기(텀블리)"

🔉 R&R

분야	이름	포지션
기획	박형준	📈 PM, 서비스 기획
기획	김대헌	📈 서비스 기획
기획	이수영	📈 서비스 기획
디자인	권예인	📢 서비스 디자인
개발	김승훈	📱 Web 화면 UI 구현, 서버 연동
개발	안재국	📱 Web 화면 UI 구현, 서버 연동
개발	오진영	💻 DB 및 API 구축
개발	한호정	🖥️ DB 및 API 구축, 서버 배포

📺 시연 영상

default.mp4

🔍 System Architecture

💻 Technology

• Web
  • 
  • 
  • 
• Server
  • 
  • 
  • 
• Co-working Tool
  • 

📢개발팀 행동 강령📢

📕 커밋 컨벤션

커밋 메세지는 [기능 키워드, 커밋 내용]으로 작성할 것!

ex) git commit -m "feat: 분기별 랭킹 화면 추가

• feat : 새로운 기능 추가
• fix : 버그 수정
• chore : 빌드 업무, 패키지 매니저, 라이브러리, dependencies 설정
• docs : 문서 수정 - ex) README.md
• design : 사용자 UI 디자인 변경 - ex) CSS
• style : 기능 수정 없는 코드 스타일 변경
• refactor : 코드 리팩터링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• ci : ci 설정 파일 수정
• perf : 성능 개선
• rename : 파일 혹은 폴더명 변경
• add : 파일 추가

📙 Git Flow 전략

• main : 출시 가능한 프로덕션 코드의 브랜치
  • Tag를 이용하여 배포 버전 명시
• develop : 다음 버전을 개발하는 브랜치
• feat : 기능을 개발하는 브랜치
  • feat/개발할 기능으로 네이밍 할 것
  • main 또는 develop으로 merge할 때는 --no-ff 반드시 사용할 것
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

📘 작업 방식 - 회의

1. main → develop 분기
   • 최신 배포 직후에는 main과 develop 변경 사항이 동일함
2. develop → feat/{기능 이름} 분기
3. 작업 후 feat → develop PR
   1. 충돌 해결 및 테스트 코드 pass 확인 (CI)
4. 코드 리뷰 진행
   1. 최소 1번
5. feat → develop Merge
   1. Squash and Merge
   2. merge 후 feat 브랜치 자동 삭제
6. 배포 시점에 develop → main PR 및 Merge
   1. Merge commit or Rebase and Merge
   2. CI/CD 작동
7. 애플리케이션 장애가 발생하면 main → hotfix/{문제상황} 브랜치로 분기
   1. 버그를 고치고 main으로 merge