[Re|view] 2. 프로젝트 진행 방식 정립

📝 커밋 컨벤션

양식

<타입>(<스코프>): <제목>

<본문>

<푸터>

타입

• init: 프로젝트 시작, 초기화
• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 스타일이나 포맷팅 변경 (기능에 영향을 주지 않음)
• refactor: 코드 리팩토링 (기능 변경 없이 내부 구조 변경)
• test: 테스트 코드 추가 또는 수정
• chore: 빌드 및 도구 설정 변경 등 잡일

스코프

• 변경된 코드의 범위나 모듈을 명시
• 예) backend, frontend, auth, db

제목

• 커밋의 내용을 간략히 설명

본문

• 제목만으로 충분히 설명되지 않는 경우 상세 내용을 작성
• 한 줄에 72자를 넘지 않도록 할 것

푸터

• 관련된 이슈나 PR, 브레이킹 체인지 등을 언급하는 용도

주의 사항

• 커밋 메시지를 작성 시 변경 사항의 목적과 영향을 명확히 할 것
• 커밋은 가능한 작게 쪼개서, 한 번에 하나의 기능이나 수정에 집중할 것
• 주기적으로 커밋 메시지 일관성을 점검할 것

🔀 Github-Flow 전략

출처: https://mungto.tistory.com/450

혼자서 진행하는 프로젝트이고, 개발 과정에 깃허브의 요소를 최대한 사용해보고 싶어 Github-Flow 전략으로 브랜치를 관리하기로 했다.

👶 첫 이슈, PR 생성

이슈 생성

init 브랜치 생성해 커밋 후 PR 생성

혼자서 하는 개인 프로젝트지만 나중을 위해 이슈나 PR을 만들면서 작업하는 것에 익숙해지면 좋을 것 같아 이슈와 PR을 활용하며 프로젝트 진행을 해보기로 했다. 이런 건 처음이라 일단 이 블로그를 참고해 이슈와 PR을 생성해보았다. 추후 템플릿을 따로 만들어 이슈와 PR을 생성할 계획이다.