Portfolio


# 브랜치 전략

참고자료 링크

> 참고로 release 브랜치는 뺐습니다. 소규모 프로젝트에선 오히려 복잡도만 높일 것 같습니다.

## 브랜치 종류

### main

- 최상위 브랜치
- 완성되어 테스트가 끝난 develop 브랜치의 코드를 병합

### develop

- 개발된 기능을 다른 사람들 코드와 병합
- 필연적으로 충돌 발생
  - 충돌은 개인 로컬 브랜치에서 전부 해결하고 푸시해야됨
- 충돌 해결 후 테스트 필수

### feature

- 실질적으로 기능을 개발하는 브랜치
- 개발 완료된 기능은 우선 해당 feature 브랜치에 푸시하고 develop으로 PR 작성
- 리뷰어의 요청사항을 로컬에서 수정 후 푸시
- develop으로 merge가 완료된 feature 브랜치는 삭제

### hotfix

- develop이나 main에서 버그, 에러 발생시 수정을 위한 브랜치
- 버그나 에러에 대한 내용을 담은 이슈 생성
- 해당 이슈 번호로 네이밍

<br>

## 브랜치 네이밍 규칙

### main, develop

- 이름 그대로 사용

### feature

- `feature/{기능명}`
- 기능명 : kebab-case

ex) feature/landing-page

> 애매한 경우 회의에서 결정

### hotfix

- `hotfix/{이슈번호}`
- 버그에 대한 이슈 생성 후 이슈번호로 브랜치 이름 작성

ex) hotfix/13

Feat	새로운 기능을 추가(수정)할 경우	Feat: 회원가입 폼 추가 Feat: 로그인 버튼 수정
Fix	버그를 고친 경우	ㅤ
Style	코드 포맷 변경(오타 수정, 탭 사이즈 변경, 변수명 변경), 세미 콜론 누락, 코드로직 수정이 없는 경우	ㅤ
Design	CSS등 사용자 UI 디자인 변경	ㅤ
Comment	필요한 주석 추가/삭제/수정한 경우	ㅤ
Rename	파일 혹은 폴더명을 수정하거나 옮기는 경우	ㅤ
Refactor	프로덕션 코드 리팩토링	ㅤ
Chore	빌드 태스크 업데이트, 패키지 매니저 설정 (실제 production 코드 변경은 없음) ex. package.json 변경, 그외 자잘한 것	ㅤ
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우	ㅤ

깃허브 컨벤션

1. Commit

2. Branch

3. Pull Request

4. Merge