⚙️ Ground Rule

🤝 Collaboration

우리 팀은 효율적인 협업을 위해 다음 도구들을 활용합니다

GitHub Discussions

 - 프로젝트 관련 토론 및 아이디어 공유
 - 주간 회의 안건 및 결과 정리 (일일 회의)
 - 기술적 의사결정 기록 (멘토링 일지)

디스커션 바로가기

GitHub Projects

 - 스프린트 계획 및 작업 항목 관리
 - 각 작업의 진행 상황 추적
 - 마일스톤 및 릴리스 계획 수립

웹툰 프로젝트 바로가기

Discord

 - 실시간 커뮤니케이션 및 빠른 의사결정
 - 기술 지원 및 문제 해결을 위한 채널 운영

Wiki

 - 개발 환경 문서화
 - 도입 기술 문서화

맨 위로 ↑

💬 Git Commit Convention

Commit Structure

 - 커밋 메시지 작성 시 주의사항
 1. 제목은 50자 이내로 제한

 2. 제목의 형식: `\<type> \<title>`
     - `type`과 `scope`는 반드시 영문 소문자로 작성
     - `title`은(는) 첫 글자만 대문자(영문 기준)로 시작

 3. 제목 끝에 마침표 생략

 4. 제목 작성 규칙
     - 영문: 동사 원형으로 시작하는 명령문으로 작성 (예: "Add feature", "Fix bug")
     - 한글: 명사형으로 끝나도록 작성 (예: "기능 추가", "버그 수정")

 5. 본문은 한글 또는 영문으로 작성 가능하며, 20자마다 줄바꿈 (적절 길이를 유지해 주세요!)

 6. 본문은 "어떻게"보다 "무엇을", "왜"에 초점을 맞춰 작성

커밋 메시지 구조

<type> <title>

<body>

<footer>

예시(영문)

feat Implement createUser method

- Add createUser method in UserService
- Implement input validation for user data
- Create unit tests for createUser method

something if needed

예시(한글)

feat CreateUser 메소드 구현

- UserService에 createUser 메소드 추가
- 사용자 데이터에 대한 입력 유효성 검사 구현
- createUser 메소드에 대한 단위 테스트 작성

추가 설명이 필요할 시 작성

예시(한글-영문 혼합)

feat UpdateUser 메소드 성능 최적화

- Implement caching for frequently accessed user data
- 데이터베이스 쿼리 최적화로 응답 시간 50% 단축
- Add logging for tracking update operations

추가 적인 설명이 필요하다면 작성

Commit Types

Type	설명
feat	새로운 기능 추가
bug	버그 수정
docs	문서 수정
style	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
refactor	코드 리팩토링
test	테스트 코드, 리팩토링 테스트 코드 추가
chore	빌드 업무 수정, 패키지 매니저 수정
question	추가 정보 요청
wontfix	수정 하지 않은 이슈 (문제가 아니거나 당장 수정 불가)

각 커밋 타입의 의미

feat: 새로운 기능 개발 관련 커밋
bug: 버그 수정 관련 커밋
docs: 문서 작성 및 수정 관련 커밋
style: 코드 스타일 혹은 포맷 등에 관한 커밋
refactor: 코드 리팩토링에 대한 커밋
test: 테스트 코드 수정에 대한 커밋
chore: 그 외 자잘한 수정에 대한 커밋 (빌드 스크립트 수정 등)
question: 프로젝트에 대한 질문 혹은 추가 정보 요청
wontfix: 수정하지 않기로 결정한 이슈에 대한 커밋

맨 위로 ↑

🌿 Branching Strategy

Github Flow 전략

GitHub Flow는 간단하고 효과적인 브랜칭 전략으로, 지속적인 배포를 지원합니다. 이 전략의 핵심은 main 브랜치와 기능별 브랜치의 사용입니다.

1. main 브랜치
   - 항상 안정적이고 배포 가능한 상태를 유지합니다.
   - 모든 변경사항은 이 브랜치에 병합됩니다.

2. 기능 브랜치
   - 새로운 기능 개발이나 버그 수정을 위해 생성합니다.
   - main 브랜치에서 분기하여 생성합니다.
   - 명명 규칙: `작업유형/기능명`
   - 예: `feat/payment-gateway`, `fix/login-error`

작업 흐름

1. 새 기능 개발 또는 버그 수정 시
   - main 브랜치에서 새 브랜치를 생성합니다.

2. 사용 중인 작업유형(ex. feat) 재활용
   - `style`, `refactor`, `test`, `chore`, `question`, `wontfix`와 같은 커밋 타입은
      feat 브랜치에서 작업을 수행합니다.

맨 위로 ↑

🔀 Pull Request Guidelines

Code Review Process

1. 리뷰어 지정
   - 최소 3명의 리뷰어를 지정합니다.
   - 가능하다면 해당 기능 또는 영역에 익숙한 팀원을 포함시킵니다.

2. 피드백 제공 및 수용
   - 리뷰어는 건설적이고 구체적인 피드백을 제공합니다.
   - PR 작성자는 모든 피드백에 대해 응답하고, 필요한 경우 수정합니다.

3. 승인 및 병합
   - 최소 2명의 승인이 있어야 병합이 가능합니다.
   - 모든 CI/CD 검사를 통과해야 합니다.

4. PR에 관련된 이슈는 Development에서 추가합니다.

PR Template Example

## 개요
<!---- 변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게보다 무엇을 왜 수정했는지 설명해주세요. -->

## PR 유형
어떤 변경 사항이 있나요?

- [ ] 새로운 기능 추가
- [ ] 버그 수정
- [ ] CSS 등 사용자 UI 디자인 변경
- [ ] 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
- [ ] 코드 리팩토링
- [ ] 주석 추가 및 수정
- [ ] 문서 수정
- [ ] 테스트 추가, 테스트 리팩토링
- [ ] 빌드 부분 혹은 패키지 매니저 수정
- [ ] 파일 혹은 폴더명 수정
- [ ] 파일 혹은 폴더 삭제
- [ ] 코드 중간 통합

## PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.

- [ ] 커밋 메시지 컨벤션에 맞게 작성했습니다.  Commit message convention 참고  (Ctrl + 클릭하세요.) 
- [ ] 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).

맨 위로 ↑

Ground Rule - 3sam5oh/webtoon-search-service GitHub Wiki

⚙️ Ground Rule

🤝 Collaboration

💬 Git Commit Convention

Commit Structure

Commit Types

🌿 Branching Strategy

Github Flow 전략

작업 흐름

🔀 Pull Request Guidelines

Code Review Process

PR Template Example

⚠️ GitHub.com Fallback ⚠️

Ground Rule - 3sam5oh/webtoon-search-service GitHub Wiki

⚙️ Ground Rule

🤝 Collaboration

💬 Git Commit Convention

Commit Structure

Commit Types

🌿 Branching Strategy

Github Flow 전략

작업 흐름

🔀 Pull Request Guidelines

Code Review Process

PR Template Example

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️