Github Rule

본 글을 CI/CD가 적용되기 전 작성된 글이므로, CI/CD후와 다를 수 있습니다.

개발할 일이 생겼을 때.

1. 코드 리뷰가 필요한 개발을 진행할 때 (ex) 기능 개발...,

1. Issue를 생성합니다.
2. 이슈에 Assignee를 자신으로 설정합니다.
3. 이슈의 development에서 브랜치를 생성 후 머지합니다.
4. 개발을 마친 후 PR을 생성합니다. PR에는 자신이 사용한 기술의 도입 이유 혹은 코드를 작성할 때 어떤 생각을 하면서 작성했는지에 관한 내용을 상세히 기술합니다.
5. PR 생성후엔, 정적 코드 품질 관리 툴의 피드백을 처리합니다.
6. 자신의 코드에 대한 리뷰 진행합니다.
7. 팀원에게 코드 리뷰를 부탁합니다.
8. 코드 리뷰를 처리하고, Approval이 2 이상 되었을 때, 머지를 진행합니다.

2. 코드 리뷰가 필요없는 개발을 진행할 때 (ex) Dto 수정...,

1. 바로 서버에 적용해도 되는 것이면, 바로 master에 push합니다.
2. 프론트엔드와 함께 배포해야하는 것이면, 따로 branch를 생성 후 머지합니다.

브랜치 명명 규칙

브랜치 명명 규칙을 다음과 같습니다. feat|fix|refactor|style|docs|test|chore 중 1/#이슈번호

커밋 컨벤션은 다음과 같습니다. feat|fix|refactor|style|docs|test|chore 중 1(도메인 명): 진행한 내용에 대한 요약

regax: (feat|fix|refactor|style|docs|test|chore)([^)]+): .{1,50}(\n.{1,72})?$