Git 컨벤션

브랜칭 전략

• 브랜칭 전략으로 git-flow를 따른다.
• release branch는 별도로 운영하지 않고 배포는 master branch에서 진행한다.
• 각 기능단위 작업은 개인별로 fork한 저장소 내 feature 브랜치에서 진행한다.
• 작업이 완료되면 upstream/develop 브랜치로 PR을 보낸다.
• 리뷰가 완료된 후 merge할 때에는 squash 옵션을 적용한다.

origin 브랜치

종류

• feature: 기능개발 브랜치. origin에서만 사용한다.
• refactor: 리팩토링용 브랜치. origin에서만 사용한다.

origin 브랜치 명명법

• '/' 는 계층구조 구분자로 사용한다.
• '-'는 단어 조합 구분자로 사용한다.

e.g. feature/user-login

커밋 컨벤션

커밋 메시지

feat : 새로운 기능 추가

fix : 버그 수정

docs : 문서 수정

style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우

refactor : 코드 리팩토링

test : 테스트 코드, 리팩토링 테스트 코드 추가

chore : 빌드 업무 수정, 패키지 매니저 수정

• 기능과 관련된 변경이 아닌경우, 괄호안에 frontend / backend / infra / chrome-extension 으로 어떤 영역의 작업을 했는지 명시한다.

커밋 메시지 예시

• 기능과 관련된 변경인 경우

feat(subway): Line 추가

- 기본생성자 추가
- getter를 추가

• 기능과 관련된 변경이 아닌 경우

chore(backend): JPA 관련 의존성 추가

pull request 컨벤션

기본 설정

• upstream develop 브랜치에 merge 요청을 한다.
• reviewers: Assignees외 모든 팀원 (프론트 개발이 포함된 경우 준 코치도 포함한다.)
• assignees: 해당 기능 작업자
• milesstone: 해당 주차 스프린트 설정

PR 메시지

• 제목
  • 제목은 커밋 메시지와 동일한 방식으로 작성한다.
  • 커밋메시지 작성과 다른 점
    • 기능과 관련 된 변경이 아닌 경우, 작업한 영역은 라벨로 등록한다.
  • 맨뒤는 구현 기능과 관련된 이슈 번호 등록 (여러 이슈를 다룬 경우, 콤마로 구분해 명시한다.)

e.g. feat(backend): 북마크 기능 개발 (#91, #92, #94)

• 본문
  • 제목에 등록했던 각 이슈 처리 명령문을 명시한다.

e.g.
resolve #91
resolve #92
resolve #94

Review

Review

• 리뷰어들 전원 approve 후 해당 요청을 merge한다.
  • 충돌 나지 않으면 마지막 approve한 리뷰어가 merge한다.
• 충돌이 나면 다 같이 conflict 해결한 후에 다시 모든 리뷰어들에게 approve 받는다.

merge

• merge는 squash 옵션으로 한다.
• merge할때 커밋 메시지는 PR명과 동일하게 작성하되, 맨뒤에 (#PR번호) 를 추가로 명시한다.

e.g.
feat(기능명칭): 북마크 기능 개발 (#97)