팀 프로젝트 시작 전, 반드시 정해야 할 협업 규칙1 (Git)

1. 깃(Git) 브랜치 전략

👉 최종 브랜치 전략 

main                 # 배포용 (직접 수정 금지) 
develop              # 통합 개발 브랜치 
feature/이름-기능    # 기능 개발 브랜치

 

👉 브랜치 네이밍 (기능 기준 + 사람)

🟢Boo (공병우 - 주식 & 일부 데이터)

feature/boo-stock-data
feature/boo-stock-prediction
feature/boo-stock-news-analysis
feature/boo-stock-sentiment

 

🟢 Min (정민아 - 크립토 + 챗봇 핵심)

feature/min-crypto-price
feature/min-crypto-buzz
feature/min-chatbot-core
feature/min-chatbot-summary
feature/min-chatbot-sentiment

 

🟢Koo (구도연 - 소비 + 데이터)

feature/koo-consumption-analysis
feature/koo-consumption-visualization
feature/koo-consumption-prediction
feature/koo-recommendation

---

공통 AI 기능 (중요) - 미정

👉 여기 충돌 많이 남 → 명확히 나눠야 함

feature/ai-common-qa
feature/ai-common-summary

 

👉 대신 내부 역할 분리 👇

• min: 챗봇 UX + 인터페이스
• Boo: 주식 데이터 연결
• Koo: 소비 데이터 연결

---

2. 커밋 메시지 컨벤션 (필수 규칙 정리)

팀 프로젝트에서는
👉 커밋 메시지만 보고도 “누가, 무엇을, 왜 했는지” 알 수 있어야 합니다.

---

📌 1. 기본 구조

type: Subject

• type: 작업 종류
• Subject: 작업 내용 (간결하게)

📌 2. 예시

feat: 로그인 기능 구현
fix: 회원가입 에러 수정
refactor: 인증 로직 구조 개선

 

📌 3. 타입 (Type) 정의

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정 (README 등)
• style: 코드 스타일 변경 (기능 영향 없음)
• refactor: 코드 구조 개선 (기능 변화 없음)
• test: 테스트 코드 추가
• chore: 설정, 빌드 등 기타 작업

📌 4. 작성 규칙

• 한 줄로 간결하게 작성
• 50자 이내 권장
• 동사로 시작 (구현, 수정, 추가 등)
• 불필요한 설명 ❌ (상세 내용은 PR에 작성)

📌 5. 좋은 vs 나쁜 예시

❌ 나쁜 예시

수정
로그인 고침
코드 변경

👉 무엇을 했는지 알 수 없음

 

✅ 좋은 예시

feat: JWT 기반 로그인 기능 구현
fix: 로그인 시 토큰 만료 오류 수정

👉 작업 내용이 명확함

 

📌 6. 팀 규칙

• 커밋 메시지 형식 통일 (반드시 준수)
• 의미 없는 커밋 메시지 금지
• 하나의 커밋 = 하나의 작업

---

2-1. PR 규칙 (초간단 요약)

📌 기본

• PR 없이 merge 금지
• 모든 코드는 PR → develop

📌 방향

feature/* → develop

 

📌 작성

## 작업 내용
## 변경 사항
## 리뷰 포인트
## 관련 이슈

 

📌 규칙

• 팀장 승인 후 merge
• PR은 작게 (기능 단위)
• 하루 1회 이상 PR 권장

📌 금지

• main으로 PR ❌
• 리뷰 없이 merge ❌

📌 PR 작성 내용 (템플릿)

 

## 작업 내용
챗봇 기본 기능 구현

## 변경 사항
- 뉴스 요약 기능 추가
- 감정 분석 연결

## 리뷰 포인트
- 응답 속도 확인 부탁드립니다

## 관련 이슈
- PROJ-12