36-COLLABORATION-WEB-INTERPARK-TICKET

AT SOPT 36기 합동세미나 인터파크 티켓 🌐 🎟️

🛠️ 기술 스택

Language, Framework, Library

• TypeScript 정적 타입 체킹을 통해 안정성과 유지보수성을 높이고, 대규모 코드베이스 관리에 유리합니다.

• React 컴포넌트 기반 UI 라이브러리로, 재사용성과 렌더링 효율성이 뛰어납니다.

• Vanilla-Extract TypeScript 기반의 CSS-in-TypeScript 솔루션으로, 정적 타입 안전성과 테마 관리에 용이합니다.

• Vite 빠른 번들링과 개발 환경을 제공하는 프론트엔드 빌드 도구입니다.

• Zustand 가벼우면서도 직관적인 전역 상태 관리 라이브러리입니다.

• React Query 서버 상태 관리와 비동기 데이터 처리를 위한 라이브러리입니다.

• axios HTTP 클라이언트 라이브러리로, 네트워크 요청을 간편하게 처리할 수 있습니다.

• ESLint & Prettier 코드 스타일 자동화 및 일관성 유지를 위한 도구입니다.

📦 패키지 매니저

• yarn 빠른 속도와 일관성 있는 의존성 관리를 제공하는 패키지 매니저입니다.

---

⚙️ CI/CD

• Vercel GitHub 연동으로 자동 배포가 가능하며, 프론트엔드 프로젝트에 최적화된 배포 플랫폼입니다.

---

🤝 협업 도구

• Notion: 문서화 및 일정/작업 관리
• Discord: 가상 오피스 협업 공간

---

📂 Git / PR / Branch / Commit 규칙

🌳 브랜치 전략

• 메인 브랜치(Main branch)

  • main: 배포 가능한 상태를 관리합니다.
  • develop: 통합 브랜치 역할을 하며, 기능 개발은 모두 이 브랜치 기반으로 진행합니다. 모든 기능이 안정적으로 동작하고 배포 가능할 때 main에 merge합니다.

• 피쳐 브랜치(Feature branch)

  • develop에서 분기합니다.
  • 작업 완료 후 develop 브랜치로 PR을 보냅니다.

🌴 Branch 생성 규칙

• 작업 시작 시 이슈를 생성하고, 해당 이슈 기반으로 브랜치를 만듭니다.

• 브랜치 생성은 반드시 develop 기준으로 합니다.

• 브랜치 네이밍: 구현기능종류/기능명/#이슈번호

  • feat/login/#43
  • refactor/edit-modal/#75

---

📝 Commit Message 규칙

모든 작업은 develop에서 분기된 feature 브랜치에서 진행합니다.

• 커밋 메시지 형식:

  커밋유형: 작업 내용
  

• 예시:

  feat: 타임테이블 기능 추가
  

커밋유형	의미
feat	새로운 기능 추가
refactor	코드 리팩토링
fix	버그 수정
chore	패키지 매니저, 설정 세팅
init	초기 세팅 및 종속성 추가 관련
docs	문서 수정
design	css 및 UI 변경
style	코드 formatting, 세미콜론 누락 등 코드 로직에 영향 없는 변경
test	테스트 코드 추가/수정

---

🔀 브랜치 병합 규칙

• 메인 브랜치(main, develop)에 직접 커밋 금지 → 반드시 PR → merge 방식만 허용

1. 작업 전 항상 git pull origin develop으로 최신화 후 시작
2. PR 작성 시 PR Template에 맞게 작성
3. PR 작성 시 이슈 번호를 태그로 포함
4. PR은 1명 이상 팀원의 approve 필수
5. squash merge 방식 사용
6. PR → 리뷰는 하루 안에! 리뷰 피드백 반영도 하루 안에!
7. merge 후 작업 브랜치 삭제