몰¿룸?(MOREROOM)

SSAFY 특화 PJT

---

🗓️프로젝트 진행 기간

2024-08-19 ~ 2024-10-11 (약 8주)

---

📑주제

방탈출 테마 추천, 파티 매칭 및 방탈출 기록 서비스

---

📽️  UCC

https://youtu.be/7PE7mgw4Fow

---

❤️  팀원 소개

---

🎁  프로젝트 기획

🎉  기획 배경

🎈  기대 효과

---

👊  주요 기능

---

🖥️  서비스 화면

메인화면

---

테마검색

카페조회

---

리뷰 조회

---

리뷰 작성 및 수정

---

기록 조회 및 작성

---

파티 매칭 요청

파티매칭 및 채팅방

---

🧱 설계

🧭 ERD

---

🧶 API

회원관리

---

테마

---

카페

---

리뷰

---

기록

---

추천

---

파티요청

---

파티

---

⌚ FIGMA

---

기술스택

---

🧳 컨벤션

깃랩 커밋 & 이슈 사용

라벨

• ✨ Feat : 새로운 기능의 개발
• 🔧 Fix : bug fix, refactoring
• 📐 Chore : 개발환경 세팅, 문서 작성, 배포 이슈
• 📣 Merge : branch merge, pull request
• 🙏 Request : FE 혹은 BE 팀에게 요청할 내용, 급한 버그 사항 등록

이슈 컨벤션

• 이슈 단위는 너무 크지 않고 적당하게

이슈 제목 작성 규칙

[FE or BE/라벨 종류(이모지 없이)] 알아보기 쉽게 제목 작성

ex) [FE/Feat] 포스트 업로드 버튼 디자인

• label 설정
• assigneess 설정

이슈 템플릿

## 📔 Description

<!-- 왜 이슈를 열었는가 -->

## 🐈 Todo

<!-- 무엇을 할 것인가를 체크박스로 만들고 작업이 끝날 때마다 체크하면서 진행 -->

- [ ] todo1

etc…

• 이슈를 자동으로 닫기 위해서는 close 키워드 추가
• 브랜치 생성은 반드시 이슈를 기반으로 생성

커밋 컨벤션

커밋 메시지 작성 규칙

fe & be/커밋 종류: 작업 요약 (ing) -> 작업이 덜 끝났을 때에만 쓰에요

주요 변경 내용1
 - 주요 변경 내용1 에 대한 세부 사항 // 필수 아님

주요 변경 내용n
 - 주요 변경 내용n 에 대한 세부 사항
 
#이슈번호

# ----- 예시 ------ #
############################
fe/feat: post upload btn design
 
포스트 업로드 버튼 디자인
 - 로직 미완성, 단순 디자인
#3

단, merge request 는 좀 다름

[MR]: #source이슈 번호 -> target 브랜치

ex) [MR]: #10 -> fe 

머지 리퀘스트 컨벤션

머지 리퀘스트 제목 작성 규칙

[FE or BE/관련 이슈 종류(이모지 없이)/#관련이슈번호1, #관련이슈번호2] 제목

ex) [FE/Feat/#10] 포스트 업로드 버튼 디자인

• reviewer 설정
  • reviewer 는 mr 을 작성하는 본인 제외 파트 팀원 전부
  • 모두에게 review 를 받고 수정사항이 필요하다면 수정이 이루어진 후에야 merge 가능
• assigneess 설정
  • mr 을 작성하는 본인 혹은 해당 작업에 투입된 파트원들 전부

mr 내에서 merge 수행 시 커밋 네이밍

[MR]: #source이슈 번호 -> target 브랜치 

ex) [MR]: #51 -> be

머지 리퀘스트 템플릿

• 반드시 상세하게 적어주세요
• 머지 리퀘스트는 본인이 해당 이슈들에서 작업했던 내용들을 기록하는 공간으로 정리가 안되면 파트원들이

## 🥥 Contents

뭐뭐 하도록 수정했습니다.

code block

<!--
코드, 개발 관점에서 어떤걸 고쳤는지 상세하게
사진같은걸 넣어도 된다.
pr 보는 사람이 따로 정보를 안 찾아봐도 되게 적는게 이상적
-->

## 📸 Screenshot

<!-- 움짤을 넣어주는게 가장 좋고, 웬만하면 용량을 작게 만든다. -->

## ⚓ Related Issue

<!-- 이슈 번호를 적어주면 되고, close 같은 자동 닫힘을 등록하여도 된다. -->

## 📚 Reference

<!-- 자신이 참조한 정보의 출처를 적는다. -->

☑️ 브랜치 양식

---

브랜치 컨벤션(GIT FLOW)

- master : 완성되어 배포, 서비스 제공이 가능한 브랜치
- develop : 개발 사항 통합 브랜치, 배포를 위한 테스트 진행 직전
- feature : 각 개발자들이 개발을 위해 develop 으로부터 파생시킨 브랜치
- release : 도메인 단위로 개발이 되면 develop 으로부터 파생되어 테스트 진행, 문제가 발생하면 해결 후 develop 과 master 로 흡수
- hotfix : 테스트가 완료되어 배포된 master 에서 문제가 발생할 시 hotfix 브랜치를 열어 빠르게 수정

• 기본적으로 feature/fe or be:적던대로-적으면됨 으로 시작하는 브랜치에서 개발
• 개발이 마무리되면 develop 브랜치로 merge request
  • develop 으로 올리 때 squash 합시다
• 특정 개발 범위 단위(도메인)로 개발이 완료되면 develop 으로부터 release 브랜치 따와서 테스트 진행
• 수정과 테스트가 완료되면 develop 과 master 로
• master 에서 최신본 배포
• 만약 배포 상황에서 문제가 발생하면 hotfix 브랜치를 열어서 수정

브랜치 이름 작성 규칙

기존 사항 -> 태그 종류(이모지 없이)/이슈 번호-소문자-소문자-소문자...
변경 사항은 아래 예시로

ex) 
feature - feature/frontend or backend/10-post-upload-button-design
release - release
hotfix - hotfix/13-api-url-fix