버져닝

• major.minor.patch

major & minor 버젼

• 정식 개발 프로세스 (일반적인 개발 프로세스)
• Sprint Development Life Cycle
• 일정 산출 > Sprint 에서 진행할 작업들을 추린다 > 개발 진행 > 작업들을 모아서 Release!

patch 버젼

• 작업 Sprint 와는 별개로, 별도의 플래닝 없이 자유롭게 작업 & 배포 가능
• 버그 수정
• 기능에 변화가 없거나 변화가 미미한 작업
• 하위 버젼 호환 필수

git 개발 flow

1. Issues 에서 이슈 생성 (작업 티켓) 생성
2. dev 에서 작업 브랜치 딴다

• [2-1] 일반 개발: feat/[issue number]-optional-explanatory-postfix (e.g. feat/123-sthg-task)
• [2-2] 핫픽스: hotfix/[issue number]-optional-explanatory-postfix (e.g. hotfix/123-urgent-task)

3. 작업 완료 후, 작업 브랜치 -> dev 로 PR
4. 작업 브랜치 -> dev PR 머지 시, Squash and merge 로 머지
5. 개발 환경에 dev 브랜치로 배포하여 기능동작 확인! (BE 배포 방법, FE 배포 방법)
6. dev -> main 으로 PR

• [6-1] sprint (major, minor version up) 개발: 모든 작업물들이 dev에 머지 완료되면 PR 날린다
• [6-2] patch (patch version up) 개발: 작업 진행자가 필요 작업들이 dev에 모두 머지 완료되었다고 판단한다면 PR 날린다

7. dev -> main PR 머지 시, Create a merge commit 로 머지
8. Releases 에 작업 내역 관련하여 릴리즈 노트 작성 (main 브랜치 기준)
9. 상용 환경에 main 브랜치로 배포하여 기능동작 확인! (BE 배포 방법, FE 배포 방법)

commit message 컨벤션

• 커밋 내용에 맞게 아래 나열된 커밋 메세지 포맷 중 하나를 골라 사용한다

- feat:
- fix:
- refactor:
- docs:
- style:
- chore:
- test:

e.g. 
feat: 로그인 구현
test: XXX 테스트 작성
...

PR 컨벤션

• 제목에 커밋 컨벤션과 같이 prefix를 붙여 기능 구현인지 수정인지 명시

e.g. 
feat: login 기능 구현

or

hotfix: login XXX 에러 버그 수정

• 기본적으로 템플릿이 존재하므로, 템플릿에 맞춰 작성하면 된다
• Close된 PR들 둘러보고 참고해봐도 좋을 것 같다

주의 사항

• FE Semantic Versioning 이 버젼 (major, minor, path 모두) 이 올라가는 상황마다 항상 적용 되어줘야 한다 (링크 참고)

코딩 컨벤션

• BE 컨벤션
• FE 컨벤션
• 찜꽁 초창기에 작성된 컨벤션이라 outdated 된 내용이 있을 수 있음. 코드로 직접 확인하는 것이 가장 정확!