commit message

github.com/angular/angular    참고할만한 오픈소스 git 사이트

beomseok95.tistory.com/328 규칙, 구조, ... 다른 게시글에 git flow도 좋음

jeong-pro.tistory.com/207

 

한글로 깃 커밋 메시지 작성하기 tttsss77.tistory.com/58

 

깃 커밋 메시지를 잘 작성해야 하는 이유

• 코드 리뷰를 빠르게 하기 위해. (speed up the reviewing process)
• 릴리즈 노트를 작성할 때 도움이 되기 때문에. (help us write a good release note)
• 심지어 5년 후에 그 코드를 다시 봤을 때 왜 그 기능이 추가됐는지, 그리고 왜 그 코드를 변경했는지 알 수 있게 하기 위해.

규칙

1. 제목과 본문을 빈 행으로 구분한다
2. 제목을 50글자 내로 제한
3. 제목 첫 글자는 대문자로 작성
4. 제목 끝에 마침표 넣지 않기
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다    한국에서는 명사로 끝내기. 개조식 구문
6. 본문의 각 행은 72글자 내로 제한
7. 어떻게 보다는 무엇과 왜를 설명한다

구조

[헤더header] type==lable(scope): <title>

 

[본문body]  헤더로 표현할 수 없는 상세한 내용을 적음, 생략 가능

 

[바닥글footer] 어떤 이슈에서 왔는지, 참조 정보들을 추가 (링킹)                              main branch로 push 할 때 닫기도 가능 공식문서링크

                   닫기: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved

- - - - - - - - - - - - - - - - - - - 

[헤더]

type

feat : 새로운 기능에 대한 커밋

fix : 버그 수정에 대한 커밋

build : 빌드 관련 파일 수정에 대한 커밋

chore : 그 외 자잘한 수정에 대한 커밋

ci : CI관련 설정 수정에 대한 커밋

docs : 문서 수정에 대한 커밋

style : 코드 스타일 혹은 포맷 등에 관한 커밋

refactor : 코드 리팩토링에 대한 커밋

test : 테스트 코드 수정에 대한 커밋

----

feature: 새로운 기능

bug: 버그 수정

update: 비즈니스 로직 변경

docs: 문서(문서 추가, 수정, 삭제)

test: 테스트

etc: 기타 변경사항

 

scope: 유효범위

subject: 아래에 상세 서술

 

---

영어

동명사(동사의 명사화)보다 명사 사용 

관사 사용 X(a(n), the)

부정문은 Don't 사용

오타수정은 Fix typo

 

하나의 작업 단위로 commit하기

 

subject

동사 링크에서 예제 보기

Fix:

A = calculation, build, error, typo, incorrect type, 충돌crash, case

B = 함수, 파일명, 클래스명, ...

Fix A

Fix A in B             발생 위치

Fix A where B     

Fix A which ~     ==

Fix A that ~          구체적인 설명(언제 발생, 어떤 것에 문제, ...)

Fix A to ~             왜 수정하는지

Fix A so that B   A를 수정해서 B가 됨

Fix A where B     B처럼 발생하는 A 수정Fix A when B       B일 때 발생하는 A를 수정

 

Add: 

코드나 테스트, 예제, 문서 등의 새로운 추가

Add A

Add A for B    무엇을 위해

Add A to B      어디에

 

Remove:

코드의 삭제만 있을 때(=Clean, Eliminate)

A와 unnecessary, useless, unneeded, unused, duplicated가 붙는 경우 많음 (형용사로)

Remove A

Remove A from B  어디에 있는

 

Use: ← 이건 예제를 봐도 대체 잘 모르겠다....

특별히 무언가를 사용해 구현을 하는 경우

Use A

Use A for B   B에 A를 사용

Use A to B    B가 되도록 A를 사용

Use A in B    B에서 A를 사용

Use A instead of B    B 대신 A를 사용

 

Refactor: 리팩토링

Simplify: 복잡한 코드 단순화(Refactor보다 약한 수정)

 

Update:

개정 / 버전 업데이트 (원래 정상적으로 작동하는 것을 수정, 추가, 보완)

Update A to B    A를 B로 업데이트 / B=버전, 새로운 이름(hello_new), 

                       A를 B하기 위해 업데이트

Revise:

특히 문서를 개정할 때 주로 사용

 

Improve:

향상 - 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성, ...

 

Make:

기존 동작의 변경(새롭게 만든건 Add 키워드 사용해야 함)

Make A B    A를 B하게 만들다

 

Make config object read-only config object를 read-only로 만듭니다.

make 'floating patch' message informational floating patch 메시지에 더 많은 정보가 담기도록 만듭니다.

Make values optional in ViewPropTypes ViewPropTypes의 값들을 옵셔널하게 만듭니다.

make read() be called indefinitely if the user wants so read()를 유저가 원한다면 무기한으로 호출되도록 만듭니다.

make IsolateData store ArrayBufferAllocator IsolateData가 ArrayBuffer를 저장하도록 만듭니다.

 

Allow:

Allow A to B     A가 B를 할 수 있도록 허용함

 

 

Implement

'Add'에 비해 더 큰 단위의 코드 추가에 사용됨

특별히 목적을 부여해주지 않아도 되는 경우 많음

Add에 비해 to나 for가 함께 사용되는 경우가 적음

ex) 모듈, 클래스

 

Implement A to B      구현 목적을 설명할 필요가 있으면

 

Correct:

주로 문법의 오류, 타입 번경, 이름 변경 등에 사용

 

Ensure:

무엇이 확실하게 보장받는다

ex) if 구문처럼 조건을 확실하게 주었을 때

 

Prevent:

특정한 처리를 못하게 막음

Prevent A              A하지 못하게 막음

Prevent A from B    A를 B하지 못하게 막음

 

Avoid:

회피하다

ex) if 구문으로 특정한 동작을 제외시킨다

 

Avoid A if B   == 

Avoid A when B       B인 상황에서 A를 회피

 

Verify:

검증 코드를 넣을 때 주로 사용

 

Move:

코드의 이동이 있을 때 사용

Move A (from C) to B   == 

Move A into B        A를 B로 옮긴다

 

Rename:

이름 변경이 있을 때 사용

Rename A to B

 

Set 

변수 값을 변경하는 등의 작은 수정에 주로 사용

Set A to B     A를 B로 설정

 

Pass A to B

파라미터를 넘기는 처리에 주로 사용

 

 

 

---

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

ull.im