Coke-Poke

Branch / PR Guide

• 본인의 대표 브랜치를 생성합니다 (Ex. 본인의 이름)
• 이후, 각 Step 마다 해당 브랜치를 베이스로 하는 새로운 브랜치를 생성합니다
  • 이 경우, 각 브랜치의 이름은 feature/{대표 브랜치 이름}_step1 과 같은 방식으로 생성합니다
  • PR은 대표 브랜치 <- Step 브랜치로 진행합니다
• PR 을 머지하기 위해선 필수적으로 1개 이상의 Approve를 받아야 합니다. PR을 올리신 이후엔 리뷰어 지정 부탁드립니다 (@jyoo0515, 본인의 리뷰어)
• 모든 step 은 테스트 코드를 포함해야 합니다
• 현 단계에서 CD 까지는 필요 없지만 CI 는 도입해서 테스트 코드와 코드 스타일(린트)이 통과하는지 확인해주세요
• (optional) Webhook 을 도입해서 CI 결과, Test Coverage 분석 결과, PR 요청, 리뷰 코멘트 등에 대해 Discord 메시지가 올 수 있도록 적용해보면 좋을 것 같습니다

Review Guide

리뷰를 하는 입장

• 상대방의 코드를 지적하는 것만이 코드 리뷰가 아닙니다. 코드를 보고 배울 점이 있다고 생각해도, 가감없이 코멘트를 달아주세요
• 코멘트를 글로 남기다 보니 오해가 생기기 쉽습니다. 리뷰 내용을 최대한 부드럽게 전달하는 것을 노력해주세요
• 왜 개선이 필요한지 그 이유를 항상 함께 남겨주세요
• 비즈니스 로직 외에도 유지보수성, 재사용성, 확장성 등에 대해 리뷰를 남기면 좋습니다
• 다른 사람의 코드를 이해하는 것은 생각보다 어렵습니다. 하지만 전체 코드를 한두번 읽어봐도 동작을 이해하기 어렵다면 좋지 못한 코드일 가능성이 있습니다. 더 읽기 쉬운 코드를 위해 피드백을 남겨주세요

리뷰를 받는 입장

• 해당 프로젝트의 경우 각 step 별로 해야할 일이 정해져 있지만 기본적으로 PR 을 열때는 본인이 작업한 내용을 이해하기 쉽게 설명해둬야 합니다. 리뷰어가 맥락 파악을 수월하게 할 수 있도록 PR 의 description 을 상세하게 적어주세요
• 모든 리뷰는 제안 사항입니다. 리뷰 내용을 굳이 반영할 필요가 없다고 생각되면 안해도 됩니다만 그 이유를 함께 코멘트로 달아주세요.
• 리뷰어는 더 나은 코드를 위한 제안을 하는 것 뿐이라는 생각을 갖고 리뷰어와 마찬가지로 부드러운 커뮤니케이션에 신경 써주세요.
• 리뷰를 받은 뒤 반영을 했다면 해당 코멘트에 commit hash 를 남겨주세요. 리뷰어가 반영 내용을 한번에 확인할 수 있어 리뷰가 수월해집니다
• 리뷰어의 코멘트를 모두 반영했거나 답장을 했다면 Re-request review 버튼을 눌러서 리뷰어에게 작업이 완료됐다는 노티를 주세요

Git Convention

포맷

type: subject;

body;

type

• 하나의 커밋에 여러 타입이 존재하는 경우 상위 우선순위의 타입을 사용한다.
• fix: 버스 픽스
• feat: 새로운 기능 추가
• refactor: 리팩토링 (버그픽스나 기능추가없는 코드변화)
• docs: 문서만 변경
• style: 코드의 의미가 변경 안 되는 경우 (띄어쓰기, 포맷팅, 줄바꿈 등)
• test: 테스트코드 추가/수정
• chore: 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X)

subject

• 제목은 50글자를 넘지 않도록 한다.
• 개조식 구문 사용
  • 중요하고 핵심적인 요소만 간추려서 (항목별로 나열하듯이) 표현
• 마지막에 특수문자를 넣지 않는다. (마침표, 느낌표, 물음표 등)

body (optional)

• 각 라인별로 balled list로 표시한다.
  • 예시) - AA
• 가능하면 한줄당 72자를 넘지 않도록 한다.
• 본문의 양에 구애받지 않고 최대한 상세히 작성
• “어떻게” 보다는 “무엇을" “왜” 변경했는지 설명한다.