Git Rules & Conventions 💻

Commit ✔️

Commit Rules

• 커밋 제목 형식은 type: title
  • 예: 'feat: 로그인 기능 구현'
• 커밋 메시지 본문은 최대한 구체적으로 작성
  • 커밋에 포함되는 파일을 명시하고 해당 파일에 대한 개발 내용을 설명

Commit Prefix

type	description
feat	기능 추가
fix	버그 수정
docs	문서 작성
refactor	코드 수정
chore	빌드 업무 수정, 패키지 추가 등
style	css, 코딩 스타일(형식, 정렬, 주석)
update	위의 사항들에 포함되지 않는 변경사항들

Branches 🎋

master

배포 가능한 버전의 코드가 있는 브랜치

• 브랜치는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 브랜치이다

develop

기능이 동작하는 상태

• feature 단위의 브랜치들이 merge되는 브랜치

feature

기능 개발을 위한 브랜치

• 브랜치 나오는 곳 : develop
• 브랜치가 들어가는 곳 : develop
• 이름 지정 : master, develop을 제외한 어떤 것이든 가능.
• 예: feat/login-be, feat/login-fe ...

hotfix

수정해야 할 부분

• 예: hotfix/modify_attr

Pull Request 🤝

PR Rules

• PR 단위 : issue 1개 = backlog의 task 1개
• 기본 원칙 : 저녁에 각자 코드리뷰 후, 다음 날 스크럼 때 머지
• 긴급 PR : PR 작성 후 슬랙이나 줌을 통해 머지 요청 -> 바로 코드리뷰 후 머지
• 별도의 해설이 없는 대신, 커밋 메세지와 PR 내용을 자세히 작성할 것

PR Conventions

• 제목
  • #[issue] - title (이슈 이름)
• 본문
  • 구현 내용
  • 이미지 (옵션)
  • 최대한 자세히 작성

[토론] PR 리뷰는 어떻게 할 것인가?

1. 하루 단위로 처리
   • 장점 : 코어타임 내에는 개발에만 집중할 수 있다.
   • 단점 : 이전 pr의 기능을 사용해야 할 때, 머지가 되지않아 다음 기능 개발에 문제가 발생할 수 있다.
2. 그때 그때 처리
   • 장점 : 브랜치 관리가 편하다. pr 요청 후, merge 전 작업을 이어나가는 것이 애매했는데 빠른 merge 이후 이어나가기 용이해짐
   • 단점 : 매 번 즉각적으로 코드 리뷰 및 승인을 해줄 사람이 필요하다. 리뷰어의 작업 흐름이 끊기기 쉬움
3. [결론] 하루 단위로 하되, 긴급 상황시 zoom을 통해 공지하여 최대한 빠르게 처리할 수 있게 한다.