🍀 LuckVII

예매 시스템의 혁신을 가져오다

---

Project Topic: 영화 앱 만들기

Project Name: LuckVII

Project Period: 12/13 ~ 12/20 12:00

Wire Frame: 🔗Figma

---

LuckVII ?

• 행운의 숫자 7과 연결되는 네임성
• Luck + VII(7)
• 럭키비키의 줄임말이자 현대스러운 네임성으로 기억에 남음
• 최초로 진행하는 랜덤 가챠 티켓 구매로 행운이 따라야 하는 앱

이 앱, 저희가 만들었습니다

팀장🎯	🎨 개발/품질	⚡️ 개발/품질	⚡️ 개발/품질	👨‍💻 개발 총괄	⚡️ 개발/품질
서문가은	김상민	김손겸	박민석	박진홍	이재훈
iOS 개발, 버그 수정 및 테스트, 전체 프로젝트 관리	UI/UX 디자인, iOS 개발, 품질 관리(QC)	iOS 개발, 품질 관리(QC), 버그 수정 및 테스트	iOS 개발, 인터페이스 구현, 품질 관리(QC)	iOS 개발, 데이터 모델링, 품질 관리(QC)	iOS 개발, 인터페이스 구현, 프로그램 설계

팀 핵심 목표

• 👨‍💻 각자 최소 1개의 기능 독립적 구현
• ⚖️ 팀원 간 균등한 업무량 분배
• 📈 개인 실력 향상
• 🤝 협업 경험 축적

기대 효과

• 🎓 실무 경험 획득
• 🔄 전체 개발 프로세스 이해
• 💪 개인 역량 강화
• 🤼 팀워크 향상

🌴 Branch Rules & Strategies

1. main 브랜치에 프로젝트 기본 세팅

   • README 작성
   • .gitignore 파일 작성
   • 프로젝트 파일 생성(Xcode)
   • 코드베이스 기본 세팅 (스토리보드 삭제, info 설정 등)
   • 프로젝트 디렉토리 분리 (MVC)

2. dev 브랜치 생성 (main 브랜치를 기준으로)

   • 메인 브랜치에 만들어진 내용을 복제
   • 작업 브랜치(Default)를 dev 브랜치로 설정

3. 이슈 브랜치 생성하기

   • 이슈 생성 후 Create a branch 버튼을 클릭하여 새로운 브랜치를 생성
   • 브랜치 이름은 작업번호-작업-제목의 형식으로 작성.
   • 작업번호는 이슈 번호를 의미함.
   • 작업-제목은 영어로 작성.

4. 이슈에는 다음 내용을 포함함

   • 개요: 작업에 대한 간단한 설명
   • 작업 내용: 구체적인 작업 내용 및 절차
   • 작업 목적: 작업의 필요성 및 기대 효과

5. 프로젝트 목표 달성을 위한 작업 목록 관리를 위해 백로그 생성

   • Backlog 열을 만들어 해야 할 모든 작업을 기록.
   • 백로그에서 작업을 선택해 To Do 열로 이동.
   • To Do → In Progress → Done 순으로 작업 진행.

6. PR-Merge 전략

   • PR을 작성할 때는 신규 내용, 변경 내용, 문제점 등을 상세히 작성
   • PR에 대해 코멘트를 작성
   • Merge는 팀원의 70%가 Approve 해야만 가능

7. 완성된 프로젝트를 main에 전달

   • dev브랜치에서 버그 등을 수정 후 최종 완성된 프로젝트를 main 브랜치에 전달
   • 불필요한 브랜치 삭제
   • README 수정

---

📓 Github 커밋 컨벤션 가이드

• ✨ [Feat]: 새로운 기능 추가
• 🐝 [Fix]: 버그 수정
• 📝 [Docs]: 문서 수정
• 💄 [Style]: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• ♻️ [Refactor]: 코드 리팩토링
• ✅ [Test]: 테스트 코드, 리팩토링 테스트 코드 추가
• 🎨 [Chore]: 빌드 업무 수정, 패키지 매니저 수정

🙌 풀 리퀘스트(Pull Request) 생성하기

1. 작업이 완료되면 변경 사항을 원격 저장소에 푸시(Push)합니다.
2. GitHub에서 원본 저장소로 이동하여 Pull Request를 생성합니다.
   • 베이스 브랜치: develop
   • 비교 브랜치: 작업번호-작업-제목
3. 풀 리퀘스트의 제목은 [#이슈번호] 작업 제목의 형식으로 작성합니다.
   • 예시: [#3] Add login feature
4. 풀 리퀘스트의 설명에는 작업 내용과 관련된 자세한 설명을 추가합니다.
5. Reviewers에는 코드 리뷰를 받을 전체 팀원을 선택합니다.
6. Assignees에는 자신을 선택합니다.
7. Labels에는 작업의 성격에 맞는 라벨을 선택합니다.
8. Development에는 해당 이슈를 선택합니다.

🔍 코드 리뷰 및 머지(Merge)

1. 풀 리퀘스트가 생성되면 팀원들은 코드 리뷰를 진행합니다.
2. 코드 리뷰 과정에서 나온 피드백을 반영하여 추가 커밋을 작성합니다.
3. 모든 팀원의 승인을 받으면 해당 브랜치를 develop 브랜치로 머지합니다.