본 프로젝트는 Gitflow 브랜치 전략을 따릅니다.
모든 기능 개발은 다음 흐름을 따릅니다.
- 개발하고자 하는 기능에 대한 이슈를 등록하여 번호를 발급합니다.
main브랜치로부터 분기하여 이슈 번호를 사용해 이름을 붙인feature브랜치를 만든 후 작업합니다.- 작업이 완료되면
develop브랜치에 풀 요청을 작성하고, 팀원의 동의를 얻으면 병합합니다.
- main 기능 개발 통합 브랜치 (pull request하고 동료들에게 merge요청, 확인이 오래걸리면 스스로 merge) 데모용 프로젝트이기 때문에 배포용 브랜치를 따로 두지 않습니다.
- feature/{이슈번호}{간단한설명} 새로운 기능 개발 브랜치
- fix/{이슈번호}{간단한설명} 버그 수정 브랜치
- hotfix/{이슈번호}{간단한설명} 긴급 수정 브랜치
- refactor/{이슈번호}{간단한설명} 리팩토링 브랜치
- chore/{이슈번호}{간단한설명} 기타 설정, 패키지 변경 등
- 기능개발이 완료된 브랜치는 develop브랜치에 merge합니다.
- merge된 Branch는 삭제합니다.
✅ 예시
- feature/#12-login-api
- fix/#17-cors-error
- chore/#20-env-setting
✅ Git 사용 규칙
- #이슈번호 <타입>: <변경 요약>
- <타입> 종류
태그 이름 설명
[init] 초기설정
[chore] 코드 수정, 내부 파일 수정
[feat] 새로운 기능 구현
[add] FEAT 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 파일 생성
[hotfix] issue나 QA에서 급한 버그 수정에 사용
[fix] 버그, 오류 해결
[del] 쓸모 없는 코드 삭제
[docs] README나 WIKI 등의 문서 개정
[correct] 주로 문법의 오류나 타입의 변경, 이름 변경에 사용
[move] 프로젝트 내 파일이나 코드의 이동
[rename] 파일 이름 변경이 있을 때 사용
[improve] 향상이 있을 때 사용
[refactor] 전면 수정이 있을 때 사용
[test] 테스트 코드 추가 시 사용
Java 17 gradle-8.14.2 springboot 3.4.7