브랜치 & 커밋 전략
브랜치 전략
Section titled “브랜치 전략”GitHub Flow 전략을 따르며, 별도 코드 리뷰 프로세스는 운영하지 않습니다.
장기 브랜치
Section titled “장기 브랜치”| 브랜치 | 용도 |
|---|---|
production | 운영 서버 배포 브랜치 |
test | 테스트 서버 배포 브랜치 |
production에서 새 브랜치를 생성합니다 (기능 개발, 버그 수정 등)- 작업 완료 후
test브랜치에 먼저 머지하여 테스트 서버에서 확인합니다 - 테스트 서버에서 확인이 완료되면
production브랜치에 머지합니다
브랜치 네이밍
Section titled “브랜치 네이밍”| 유형 | 접두사 | 예시 |
|---|---|---|
| 신규 기능 | feat/ | feat/kakao-alimtalk |
| 버그 수정 + 핫픽스 | fix/ | fix/payment-failure-notification |
| 리팩토링 | refactor/ | refactor/auth-middleware |
| 문서 | docs/ | docs/api-docs |
| 설정, 의존성 | chore/ | chore/gradle-update |
Merge Commit 방식을 사용하여 커밋 히스토리를 전부 보존합니다.
# Squash나 Rebase가 아닌 Merge Commit 사용git merge feature/campaign-contract