7. 기여 가이드 - LikeLionTeam/BootHouse GitHub Wiki

1. 브랜치 전략

BootHouse 프로젝트는 git-flow 전략을 기반으로 한 브랜치 관리 전략을 따릅니다. 주요 브랜치 구조는 다음과 같습니다

1-1. 브랜치 종류

main : 제품 출시 및 안정화된 코드를 포함하는 주 브랜치
dev : 개발 중인 기능들이 통합되는 개발 브랜치
- feat/{기능명} : 새로운 기능 개발하는 브랜치
- fix/{기능명} : 개발한 기능을 리팩토링하는 브랜치하거나 버그 수정하는 브랜치

2. PR까지의 프로세스

각자 로컬에서 dev 브랜치를 만들어서 개발합니다.
- 팀의 모든 개발자는 먼저 main 브랜치에서 dev 브랜치를 만듭니다.
```
# main 브랜치에서 dev 브랜치를 만든다.
git checkout main
git checkout -b dev
```
기능 브랜치 생성
- 각 기능 구현을 하기 전에, dev 브랜치에서 기능 브랜치를 생성합니다.
- 예를 들어, '부트캠프 관련 기능'을 개발한다면, dev 브랜치에서 feat/bootcamps라는 브랜치를 생성합니다.
```
# dev 브랜치에서 기능 브랜치를 만든다.
git checkout dev
git checkout -b feat/bootcamps
```

커밋할 때 형식을 지킬 것

dev 브랜치의 기능 브랜치에서 작업한 후, 커밋 메세지의 형식을 지키기 위해 아래와 같은 형식을 사용합니다.

# dev 브랜치에서 기능 브랜치를 만든다.
Feat: [커밋이름]
[커밋본문]
Related: [이슈번호]

--
Feat: Add bootcamp feature
 - Added feature to manage bootcamps
 - Implemented CRUD operations
Related: #123

기능 브랜치를 원격 저장소에 푸시하고, PR을 생성합니다.
- 작업이 완료되면, 기능 브랜치를 원격 저장소에 푸시하고 PR을 생성하여 리뷰를 요청합니다.
```
# 원격 저장소로 푸시한다.
git push origin feat/bootcamps
```
PR을 통해 리뷰를 받고, 코드 관리자가 main 브랜치를 병합합니다.
- 팀원이 PR을 리뷰하고 승인하면, 코드 관리자가 main 브랜치로 병합합니다.

3. PR 및 코드 리뷰 프로세스

3-1. PR (Pull Request) 제출 가이드

PR을 생성할 때는 다음 항목을 반드시 설정해야 합니다

Reviewers: 코드 리뷰를 담당할 팀원
Assignees: PR 작성자 본인
Labels: PR의 성격에 맞는 레이블 (예: For: Common, Type: Test 등)
Projects: 관련 프로젝트 보드

PR 제목과 설명은 명확하고 자세하게 작성합니다.

3-2. 코드 리뷰 프로세스

PR 병합은 매일 오전, 오후 브리핑 시간에 이루어집니다.
주요 리뷰어:
- 서재필 (seokin23): 백엔드 주요 기능 및 구조 검토
- 장세창 (sehan528): HTML, JS 등 프론트엔드 관련 검토

리뷰 과정

리뷰어는 코드를 꼼꼼히 검토하고, 수정이 필요한 부분에 구체적인 코멘트를 남깁니다.
- 예시: PR 링크

피드백 반영

개발자는 리뷰어의 피드백을 반영하여 코드를 수정합니다.
수정 후 다시 PR을 업데이트합니다.

병합 승인

피드백이 모두 반영되었거나 처음부터 문제가 없다고 판단되면 리뷰어가 PR을 승인하고 병합합니다.

충돌 해결

Git 충돌이 발생한 경우, 주로 리뷰어가 이를 해결합니다.
충돌 해결이 복잡하거나 모호한 경우, 해당 기능 개발자들과 함께 논의하여 해결합니다.