[git] - Commit Message Convension : 협업을 위한 커밋 메시지와 PR 잘 쓰는 법

깃으로 코드관리를 하고 협업을 할 때, 커밋과 PR은 매우 중요하다.

다른 사람이 코드를 어떻게 썼는지가 직관적으로 보이고, 어떤 작업을 했는지를 쉽게 알 수 있게 해준다.

그러나 이러한 장점을 살리려면, 커밋 메세지와 PR 내용을 직관적이고 자세하게 써주어야 한다.

커밋 메시지 예시

Feat: "게임 기능 구현"          -> 제목
date: 23/10/24                 -> 커밋을 작성한 날짜 (선택)
1.게임의 시작 , 종료 기능 구현  -> 본문
2.게임 재시작 기능 구현         -> //
3.신규 기능 테스트 코드 추가    -> //

Resolves: #67                  -> 꼬리말 (해결된 이슈)
Ref: #64
Related to: #33, #34           -> 꼬리말 (관련된 이슈)

커밋 메시지는 제목과 본문으로 나누어서 작성한다.

제목으로 설명이 충분하다면 제목만 작성해도 좋고, 변경에 대한 자세한 설명이 필요하다면 본문에 추가한다.

꼬리말에는 해결되었거나 관련된 이슈들을 작성해주면 좋다.

 

커밋 메시지 여러 줄 쓰기

 

커밋 메시지를 쓸 때 여러줄을 쓰고 싶다면, 첫 줄을 작성하고 큰 따옴표를 닫지 않고 엔터를 입력하면 다음 줄을 작성할 수 있다. 그리고 작성이 끝났다면 따옴표를 닫아주면 된다.

 

예시)

 

제목 작성 팁

Feat: "게임 플레이 기능 구현"  -> 제목

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

제목 태그에 대한 표

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

 

본문 작성 팁 (body)

1.게임의 시작 , 종료 기능 구현  -> 본문
2.게임 재시작 기능 구현         
3.신규 기능 테스트 코드 추가

• 모든 커밋에 굳이 본문을 작성할 필요는 없다
• 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성
• 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성

꼬리말 작성 팁(footer)

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

• 선택사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없다
• issue tracker id를 작성할 때 사용
• 유형: #이슈 번호 형식으로 작성
• 유형은 다음 중 하나를 사용

꼬리말 유형 예시

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

 

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷, 가장 최신의 배포된 버전
develop	develop	기능 개발을 위한 feature 브랜치 들을 병합, 테스트가 완료되고       버그가 수정되어 배포에 문제가 없을 때, main브랜치에 병합
feature	feature/이슈번호-이름 or feature/1-branch-name	develop에서 분기 후 develop에 병합
hotfix	hotfix/이슈번호 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

### 작업사항 :memo:
`해당 이슈사항을 해결하기 위해 어떤 작업을 했는지 남겨주세요.`
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

### 테스트 방법
`리뷰하는 사람이 어떻게 테스트할 수 있을지 간략히 써주세요.`


### 테스트 결과
`베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF 등`

+++

github project - settings - branches - add rule에서 Restrict who can push to matching branches 옵션 추가

위의 설정은 master 브랜치에 실수로 푸시하는 일이 없도록 푸시할 수 있는 팀원들을 제한한다. 깃을 다루는데에 익숙하지 않은 분들이 실수로 마스터 브랜치에 푸시하는 일을 예방할 수 있다.

 

자동으로 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`

 

 

reference

• https://another-light.tistory.com/71
• https://velog.io/@ye-ji/Git-PR-%EC%9E%98-%EC%93%B0%EB%8A%94-%EB%B0%A9%EB%B2%95