좋은 commit, Pull Request, branch 작성 방법

Branch 네이밍 규칙

1) master branch, develop branch

본래 이름을 그대로 사용한다. 

ex: master, develop

2) feature branch.

feature/{feature-name}  형식을 사용한다.

이때 feature-name은 소문자, 하이폰 (-)의 구성으로만 작성한다.

ex: feature/parameter-json-parser, feature/opencv-result-drawing

3) release branch

release/{version} 형식을 사용한다. 

ex: release/1.0

4) hotfix branch

hotfix/{version}, hotfix/{hotfix-name} 형식을 사용한다. 

ex: hotfix/1.0, hotfix/previous-restart-issue

 

Commit Message

💡 커밋 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 커밋에는 1개의 행위만 들어 있게 한다.
• 반드시 커밋구분 리스트를 접두사로 붙인다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

커밋구분 리스트

커밋구분	설명
FEAT	(feature)개선 또는 기능 추가
BUG	(Bug Fix)버그 수정
DOC	(Documentation)문서 작업
TST	(Test)테스트 추가/수정
BLD	(Build)빌드 프로세스 관련 수정(yml)
PERF	(Performance)속도 개선
CLN	(Cleanup) 코드 정리 / 리팩토링

[출처] Git Commit Message|작성자 리차드

title

• 커밋 구분 리스트를 접두사로 사용한다.
• 그 후 ~한다는 명령어로 시작하여 한눈에 어떤 작업을 했는지 알기 쉽게 적는다.
• 영어로 예시를 들면 Create~, Add~, Fix~, Delete~

summary

• 45자 이내로 간결하게 작성한다.

description

• summary를 풀어서 작성한다.
• description만 보고도 어떤 작업을 했는지 파악할 수 있도록 작성한다.
• 기존에서 변경된 사항이 있다면 before, after 를 명시한다.
• ex) 함수 A 리턴값 타입 변경 : int → float

 

Pull Request

💡 PR 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 PR에는 1개의 작업만 들어 있게 한다.
• 코드의 변화를 300줄 미만으로 유지한다.
• 리뷰어가 코딩 스타일을 리뷰하지 않도록 코드 컨벤션을 잘 지킨다.
• 정상적으로 동작하는지 테스트하고, 정상적인 경우에만 PR 한다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

title

• 작업한 브랜치 명을 그대로 따라 간다. 

description

• 작업 이유, 작업 내용, 리뷰어가 알아야 할 내용, 이미지 등을 상세하게 명시한다.

template

## 개요
작업하게 된 이유를 작성해주세요.

## 작업 내용
작업한 내용을 상세하게 설명해주세요.

### 추가된 사항
새로 추가한 작업에 대해 설명해주세요.

### 변경 사항
기존 내용에서 변경된 사항을 before -> after 형식으로 작성해주세요.

## 이슈
궁금한 사항 혹은 리뷰어들이 알아야 하는 이슈를 작성해주세요.

## 이미지
시각적인 설명이 필요한 경우 부가적으로 첨부해주세요.

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

ull.im

https://blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=skykbc&logNo=222016405016 

Git Commit Message