[Git] Github Convention
1. 깃헙 커밋 규칙
[타입] - 하려는 내용
형태로 작성하기,
커밋 타입 설명
타입 | 설명 | 예시 |
---|---|---|
feat | 기능 구현 | [feat] - 페인페이지 레이아웃 구현 |
rename | 파일/폴더 이름 변경 및 이동 | [rename] - src/old-folder 를 src/new-folder 로 이동 |
script | 라이브러리 추가 | [script] - supabase 라이브러리 추가 |
fix | 버그 수정 | [fix] - supabase env 미연결 문제 해결 |
chore | 주석 추가/삭제, console 제거 | [chore] - 불필요한 console.log 제거 |
refactor | 코드 리팩토링 | [refactor] - 함수 분리 및 코드 정리 |
style | CSS 코드 | [style] - 버튼 스타일 수정 |
test | 테스트 코드 | [test] - 유저 로그인 기능 테스트 추가 |
docs | 문서 수정 | [docs] - API 문서 업데이트 |
2. 브랜치 네이밍
브랜치 유형 | 네이밍 규칙 |
---|---|
main | main |
develop | dev |
feature | feat/{기능 요약} 또는 feat/{issue-number}-{기능 요약} |
release | release-{버전} |
hotfix | hotfix-{버전} |
3. 템플릿 정하기
3.1 issue 템플릿 정하기
3.2 PR 템플릿 정하기
[GitHub PR template 만들고 사용하기↗️]
4. PR 규칙
PR (Pull Request) 하기 전
- 커밋은 가능하면 자주 할 것
- 본인 github 브랜치에 push도 가능하면 자주 할 것
- PR은 너무 뜸하지 않게 주기적으로 실시할 것 (주기가 너무 뜸하면, 그만큼 검토해야할 코드가 늘어나기 때문에 그만큼 시간이 지연됨)
PR (Pull Request) 주의사항
- (중요) 반드시 검토할 사람이 있을 때 PR을 올릴 것!!
- 라이브러리를 추가한 경우, 어떤 라이브러리가 추가되었는지 PR 본문에 작성할 것
- 공통적인 부분 (ex. Route, 공통 컴포넌트, 공통 스타일 등) 을 수정한 경우, 어떤 부분을 수정했는지 PR 본문에 작성할 것
PR (Pull Request) 수행 이후에 할 일
- Slack에 PR URL 주소를 올림
- 다른 사람들이 PR을 검토하고 “승인” 하면 Merge 진행
- Slack에 Merge 했다고 메시지를 남김
Merge 수행 이후에 할 일
- Merge 성공 여부를 검토할 사람이 본인 브랜치에서 작업하던 중간 지점까지 commit
git pull origin dev
- 추가된 라이브러리가 있는 경우
yarn
yarn start
하여 충돌 여부 확인- 충돌 없이 정상 작동 시
"확인했다"
,"이상 없다"
같은 내용을 Slack에 남기기
충돌이 있을 시"어떤 부분에서 충돌이 있다"
,"충돌이 있었는데 이렇게 해결했다"
같은 내용을 Slack에 남기기
댓글남기기