[Git] Commit Message / PR 잘 쓰는 방법

ye-ji·2022년 2월 26일
5

GitHub🖤

목록 보기
1/3
post-thumbnail

커밋 메시지 규칙

커밋 메시지 예시

Feat: "로그인 기능 구현"  -> 제목

새로고침 시 로그인 유지 기능 개발  -> 본문

Resolves: #67  -> 꼬리말
Ref: #64
Related to: #33, #34

깃 이모지💚

커밋 메시지는 제목본문으로 나누어진다! 설명이 충분하다면 제목만으로도 괜찮다 하지만 어떤 변경사항이 있는지 맥락과 설명이 필요하다면 본문 혹은 꼬리말을 활용할 수 있다.

제목(Subject)

Feat: "로그인 기능 구현"  -> 제목
  • 제목과 본문을 한 줄 띄우고 콜론(:)으로 분리
  • 제목은 영문 기준 50자 이내로 적기
  • 영문 기준 동사(원형)을 가장 앞에 두기. (과거 시제를 사용하지 않기)
  • 제목 첫글자를 대문자로 적기
  • 제목 끝에 . 는 금지
  • 제목은 명령어, 개조식으로 작성

제목에 대한 표

제목 태그 이름설명
Feat새로운 기능을 추가할 경우
Fix버그를 고친 경우
DesignCSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE커다란 API 변경의 경우
!HOTFIX급하게 치명적인 버그를 고쳐야하는 경우
Style코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor프로덕션 코드 리팩토링
Comment필요한 주석 추가 및 변경
Docs문서를 수정한 경우
Test테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X)
Chore빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X)
Rename파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove파일을 삭제하는 작업만 수행한 경우

본문 (body)

새로고침 시 로그인 유지 기능 개발  -> 본문
  • 선택사항이기 때문에 모든 커밋에 본문을 작성할 필요는 없다
  • 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성
  • 72자를 넘기지 않게 작성
  • 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성
Resolves: #67  -> 꼬리말
Ref: #64
Related to: #33, #34
  • 선택사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없다!
  • issue tracker id를 작성할 때 사용
  • 유형: #이슈 번호 형식으로 작성
  • 유형은 다음 중 하나를 사용

유형 예시

제목 태그 이름설명
Fixes이슈 수정 중 (아직 해결되지 않은 경우)
Resolves이슈를 해결했을 때 사용
Ref참고할 이슈가 있을 때 사용
Related to해당 커밋에 관련된 이슈 번호 (아직 해결되지 않은 경우)

브랜치 이름 형식

종류사용패턴특징
mainmain프로덕션 스냅샷, 가장 최신의 배포된 버전
devdev릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
featurefeature/이슈번호-이름 or feature/1-branch-namedev에 병합
hotfixhotfix/이슈번호 or hotfix/#911메인에 병합

Pull request 작성하기

PR 형식

  • 코드 컨벤션을 잘 지키기

    컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋다.

  • 리뷰 가이드 잘 작성하기

    모든 코드 변경사항에는 의도가 필요하다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야하고, 줄바꿈과 같이 아주 단순한 변경이라도 그 부분을 리뷰어가 볼 필요가 없다면 "Just line change"와 같은 코멘트를 달아 명시하여 리뷰시간을 줄여줄 수 있을 것이다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법이다.

  • 작업 중, 리뷰 가능 여부를 잘 명시하기

    아직 코드를 작성 중 일때에는 [Wip](Work in Progress)를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed태그를 설정할 수 있다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이를 반복하여 명시해야한다.

  • PR 본문
  • 아래는 Github Pull Request의 템플릿으로 지정 후 해당 본문은 삭제하면 된다!
### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feat/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.

자동으로 PR 템플릿 지정하는 방법

ISSUE 형식

  • Issue 제목
[title] / body
  • 아래 형식을 복사해 Github Issue 템플릿으로 지정 후 해당 본문은 삭제하면 된다!
### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.

### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`

### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`
- 긴급도: `High`, `Middle`, `Low`

ISSUE 템플릿 등록하는 방법

profile
토마토마토

0개의 댓글