📌 Git 협업 규칙

1. 브랜치 전략

본 프로젝트는 GitHub Flow 기반으로 진행한다.

브랜치 구조

브랜치명	역할
main	배포/최종 안정 버전. 직접 push 금지. PR 리뷰를 통해 merge.
feature/*	기능 개발 브랜치. main에서 분기하여 개발 후 PR로 merge.
fix/*	버그 수정 브랜치.
refactor/*	리팩토링 브랜치.

---

2. 브랜치 네이밍 규칙

기능 개발

feature/post-create
feature/post-read
feature/post-update
feature/post-delete
feature/like-add
feature/like-remove

버그 수정

fix/post-edit-error
fix/like-count-bug

리팩토링

refactor/post-service
refactor/like-controller

---

3. 커밋 메시지 규칙

타입	설명
feat	새로운 기능 추가
fix	버그 수정
refactor	코드 리팩토링
style	UI/코드 스타일 변경
docs	문서 수정
test	테스트 코드 추가/수정
chore	빌드/환경설정/기타 작업

---

5. Pull Request 규칙

PR 제목 규칙

[feat] 게시글 작성 기능 구현
[fix] 좋아요 수 오류 해결
[refactor] PostService 구조 개선

---

6. 폴더 구조 (예시)

src
 └── main
     ├── java
     │    └── com.project
     │          ├── controller
     │          ├── service
     │          ├── repository
     │          ├── domain
     │          └── dto
     └── resources
          ├── application-example.yml
          ├── static
          └── templates

---

7. 코드 리뷰 기준

• PR은 1명 이상의 승인 필요
• 중복 코드, 불필요한 로직이 없는지 확인
• 예외 처리 적절성 검토
• 네이밍 규칙 준수 여부 확인
• 테스트 진행됐는지 확인

---

8. 협업 규칙 요약

• main 브랜치 직접 push 금지
• 모든 기능은 feature/* 브랜치에서 개발
• PR + 리뷰 승인 후 merge
• 커밋 메시지 규칙 준수
• application.yml 등 secret 파일 push 금지