Git Convention

Issue

• Issue 명은 다음과 같이 사용한다.
  • [fix] - Issue 명
  • [setting] - Issue 명
  • [page] - Issue 명
  • [component] - Issue 명
  • [docs] - Issue 명

• Issue 사용 예시

Pull Request

• 각 기능 브랜치에 대한 PR의 제목은 깃모지 prefix : 브랜치를 총괄하는 내용 으로 한다.

  • 예시 : 📄 page : 회원가입 - 학교 이메일 인증 화면(step2)

• PR 체크 리스트

  • Reviewer 지정
  • Assignees 지정
  • Label 붙이기
  • Projects 지정

Code Review

• 리뷰어의 Approve 가 1개 이상일 때, 브랜치를 머지할 수 있다.
• 코드 리뷰는 필수적으로 참여하되, 만약 리뷰 없이 이틀 경과 시에는 머지한다.
• 코드 리뷰의 우선 순위에 따라 라벨을 사용한다.
  • ex) 우선순위: 급함 , 우선순위 : 보통, 우선순위 : 낮음
• 소통을 위하여 코드 리뷰에 다음과 같은 접두사를 사용한다. (참고자료 - 코드 리뷰 in 뱅크샐러드 개발 문화)

P1: 꼭 반영해주세요 (Request changes)

리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)

작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)

작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)

작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

Branch strategy

• develop : 개발용 브랜치
• 기본적으로 commit prefix 에 따라 기능을 나누고 이에 따른 기능 branch를 만들어 사용한다.
  • 예시 : feature/{구현할 기능} : 기능 구현 branch, fix/{수정할 버그} : 버그 수정 branch
• 기능 브랜치를 develop 브랜치로 머지할 때는 squash and merge 를 사용한다.
• 개발이 완료되고, develop 브랜치를 main 브랜치로 머지할 때는 rebase and merge 를 사용한다.
• 참고 자료 : GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기

Code Review

• 리뷰어의 Approve 가 1개 이상일 때, 브랜치를 머지할 수 있다.
• 코드 리뷰는 필수적으로 참여하되, 만약 리뷰 없이 이틀 경과 시에는 머지한다.
• 코드 리뷰의 우선 순위에 따라 라벨을 사용한다.
  • ex) 우선순위: 급함 , 우선순위 : 보통, 우선순위 : 낮음
• 소통을 위하여 코드 리뷰에 다음과 같은 접두사를 사용한다. (참고자료 - [코드 리뷰 in 뱅크샐러드 개발 문화](https://blog.banksalad.com/tech/banksalad-code-review-culture/))

P1: 꼭 반영해주세요 (Request changes)

리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)

작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)

작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)

작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

Commit

• Commit 은 가급적이면 기능 당 하나의 커밋을 사용한다.
• Commit 메시지는 반드시 한글로 작성하며, 너무 길어지지 않도록 최대한 간결하게 작성한다.
  • Commit 메시지에 문장형을 사용하지 않는다.
  • Commit 메시지에 마침표를 사용하지 않는다.
• husky 를 이용한 pre-commit 을 사용한다.
• main 과 default 브랜치에 force-push 를 금지한다. (레포 설정)

Commit Message

commit prefix-convention

prefix	설명
✨ Component	컴포넌트를 구현한 경우
📜 Docs	문서를 수정한 경우
🐛 Fix	버그를 고친 경우
🆘 Help wanted	팀원의 도움이 필요한 경우
🐞 Bug	버그가 발생한 경우
📄 Page	페이지 컴포넌트를 구현한 경우
🔧 Setting	세팅을 진행한 경우