[개발] 캐플라이어 개발 환경 세팅

오늘은 Next.js 최신 버전으로 개발 환경을 세팅하고,

Github에 Repository를 만든 후 추가 학습 및 컨벤션 정리를 진행할 것 이다.

---

GitHub

jwinda/CharFlyer (github.com)

jwinda/CharFlyer

라벨

몇 가지의 라벨을 통해 이슈를 관리할 것이다.

개발 환경

npx create-next-app@latest

초기 설정	사용 여부
TypeScript	사용
ESLint	사용
Tailwind CSS	미사용
src/ 디렉토리	사용
App Router (권장됨)	사용
Import 구문	미사용

이러한 환경으로 Next.js를 설치하였다.

 

커밋 컨벤션

Git 커밋 메시지 컨벤션은 왜 중요할까? | 요즘IT (wishket.com)

Git 커밋 메시지 컨벤션은 왜 중요할까? | 요즘IT

[Git/GitHub] Commit Convention / 깃 커밋 컨벤션 사용 (tistory.com)

[Git/GitHub] Commit Convention / 깃 커밋 컨벤션 사용

해당 게시글을 기준으로 작성하였다.

Subject Rule

태그	제목
Feat :	새로운 기능 추가
Fix :	버그 수정
Docs :	문서 수정
Style :	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
Refactor :	코드 리펙토링
Test :	테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우)
Chore :	위에 걸리지 않는 기타 변경사항 (빌드 스크립트 수정, assets image, 패키지 매니저 등)
Design :	CSS 등 사용자 UI 디자인 변경
Comment :	필요한 주석 추가 및 변경
Init :	프로젝트 초기 생성
Rename :	파일 혹은 폴더명 수정하거나 옮기는 경우
Remove :	파일을 삭제하는 작업만 수행하는 경우

태그와 같이, 요점을 서술한다.

 

BodyRule

'무엇을' '왜' 변경했는 지를 설명한다.

 

FooterRule

Issue Tracker	설명
Fixes :	이슈 수정중(아직 해결되지 않은 경우)
Resolves :	이슈를 해결한 경우
Ref :	참조할 이슈가 있을 때 사용
Related to :	해당 커밋에 관련된 이슈 번호(아직 해결되지 않은 경우)

태그와 같이 "유형: #이슈 번호" 형식으로 작성한다.

 

저번 프로젝트에서는 Body Rule과 Footer Rule 까지는 따르지 않았는데, 이번에는 최대한 커밋 컨벤션을 룰에 따라 작성해보려 한다.

 

예시

브랜치 전략

글 그림 출처 *

협업을 위한 Branch 활용법 (velog.io)

협업을 위한 Branch 활용법

1. Master 브랜치
   Master 브랜치는 배포 이력을 관리하기 위해 사용되며, 배포 가능한 상태만을 관리한다.
2. Develop 브랜치
   기능 개발 브랜치를 병합하기 위해 사용된다.
   모든 기능을 이 브랜치로 병합하고 모든 버그가 수정되면 Master 브랜치로 병합한다.
3. Feature 브랜치
   Develop 브랜치에서 분기하여 사용하며, 각 브랜치가 하나의 기능 개발을 담당한다.
   기능 개발 및 버그 수정이 완료되면 Develop 브랜치에 병합되어 다른 사람과 공유하게 한다.
4. Release 브랜치
   현 버전 배포 전 다음 버전 개발을 그대로 진행하는 경우에 현 버전 배포를 위한 브랜치이다. 배포를 위한 준비는 Release 브랜치에서 진행하고, 다음 버전 개발은 그대로 Develop 브랜치에서 진행한다.
5. Hotfix 브랜치
   배포한 버전에 급히 수정해하는 사항이 발생한 경우 Master 브랜치에서 분기하는 브랜치이다.

개발 기간에는 현재의 'develop' 브랜치에서 기능별로 'feature-기능' 의 브랜치를 통해 작업한다.

기능 개발이 완료되었을 시에는 ''feature-기능' 브랜치를 develop' 브랜치로 병합한다.

금요일이나 주말에는 버그가 해결된 배포 가능한 상태의 'develop' 브랜치를 'master' 브랜치로 병합시킨다.