Git Commit Message Convention For Me

git commit을 할 때 항상 커밋 메시지를 고민하게 된다.

찾아본 git convention을 참고해 타입을 앞에 명시하고, 명령조로 마지막에 .을 찍지 않고 최대한 자연스러운 영어로 작성하려고 하는데 이 type 분류부터 항상 헷갈린다. commit시 계속 찾아보고 올리게 되는데 헷갈리는 부분 오늘 명확히 정리하고 가기로 했다!!

 

git convention은 존재하지만 사람마다 쓰는 방식이 (feat: ) (Feat : ) 등등 다양하므로 convention을 참고하여 본인의 일관되고 명확한 commit message 작성법이 존재하는 것이 좋다. 커밋 메시지를 한국어로도 많이 작성하지만 평소 github에 올리는 code는 외국분들도 봐주시기 때문에 개인 플젝은 영어로만 작성하려고 하고 있다. 물론 협업시에는 모두 동의한 방식을 사용하면 된다.

 

📎 Commit Message Convention

Commit Message Format

<type>[optional scope]: <subject>

[optional body]

[optional footer(s)]

header 다음 한 줄 띄우고 body 선택 작성, 한 줄 띄우고 footer 선택 작성하는 방식

 

한 줄 예시

feat(shopping cart): add the amazing button

 

전체 작성 예시

feat(database): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

BREAKING CHANGE: $browser.onHashChange, which was removed (use onUrlChange instead)

 

• Any line of the commit message cannot be longer 100 characters!

commit message 한 줄에 100글자 이상 넘어가지 않기!

 

나는 대부분 type만 명확히 명시해 주고 간단명료하게 작성하는 편이다.

(commit 안에 여러 타입, 기능이 있다면 body에 나눠서 적어주기도 한다)

(scope를 작성해주기도 하는데 생략 가능)

 

Revert

revert: commit <short-hash>

This reverts commit <full-hash>
More description if needed

revert시 위와 같이 작성

 

Type

feat: 새로운 기능(A new feature)

fix: 버그 고침(A bug fix)

refactor: 버그를 고치거나 기능을 추가하지 않은 코드 변화 (A code change that neither fixes a bug nor adds a feature)

perf: 성능을 개선시킨 코드 변화 (A Code change that improve performance)

docs: 문서에만 변화가 있음(Documentation only changes)

build: 빌드 시스템이나 외부 의존성에 영향을 주는 변화 (Changes that affect the build system or external dependencies/ example scopes: gulp, broccoli, npm)

ci: CI 환경 설정 파일이나 스크립트의 변화 (Changes to our CI configuration files and scripts/ example: CircleCi, SauceLabs)

test: 빠진 테스트 추가 혹은 존재하는 테스트 고침 (Adding missing tests or correcting exisiting tests)

 

 

위와 같이 타입 명시를 인지해도 가끔 타입이 헷갈리는 코드들이 있다. 예시를 통해 알아보자.

css style 추가 => feat

 

package.json 편집 => build

 

파일이름 바꾸기, 파일 지우기 => refactor, (잠재적으로 BREAKING CHANGE 추가할 수 있음)

 

 

이외에 사용하기도 하는 type 

chore: 여러 가지 종류의 커밋들, 예) .gitignore 수정(Miscellaneous commits e.g. modifying.gitignore)

style: 포맷팅, 공백, ; 빠트림 등등 코드에 의미있는 변화가 없음 (formatting, white-space, missing semi colons, etc; no code change)

 

(.. 추가 가능)

Subject

- 명령조로, 현재형으로 작성 ()

• use the imperative, present tense: "change" not "changed" nor "changes"

- 첫 번째 글자 대문자 작성 x

• don't capitalize the first letter

- 마지막에 점(.) 찍지 말기

• no dot (.) at the end

- 마지막에 GitHub 이슈 참고 표시하기, 완전히 문제가 고쳐지지 않았을 시 (refs #1234), 고쳐졌을 시 (fixes #1234)

• reference GitHub issues at the end. If the commit doesn’t completely fix the issue, then use (refs #1234) instead of (fixes #1234).

<Type>: Short description (fix #1234)

Longer description here if necessary

BREAKING CHANGE: only contain breaking change

 

아래와 같이 footer에 참고하기도 한다. 사용할 수 있는 키워드(fix, close, closed ...)도 다양하지만 일관되게만 사용하자.

fix: minor typos in code

see the issue for details on the typos fixed

fixes issue #12

 

Body

- header와 같이 명령조, 현재형으로 작성

- 변화에 대한 동기와 이것을 이전 행동과 대조

 

BREAKING CHANGE

- breaking change를 포함하는 커밋

• This commit contains breaking change(s).

breaking change란?

잠재적으로 다른 component의 fail을 유발할 수 있는 소프트웨어 시스템의 한 부분에 대한 변경, 여러 응용 프로그램에서 사용되는 공유 코드 라이브러리에서 가장 자주 발생한다.

(computing) A change in one part of a software system that potentially causes other components to fail; occurs most often in shared libraries of code used by multiple applications.

 

- 예시) feat(api)!:

위와 같이 : 뒤에 ! 명시

- [footer] BREAKING CHANGE: 로 시작, 다음 공백 또는 새로운 두 줄 이후 나머지 커밋 메시지 작성

• start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

 

예시

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.
    
    To migrate the code follow the example below:
    
    Before:
    
    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }
    
    After:
    
    scope: {
      myAttr: '@',
      myBind: '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }
    
    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

 

---

git commit message convention을 검색하면 나오는 블로그들이 많은데 각자 작성 규칙이 다른 경우가 많다. 지금까지 Subject 작성 시 첫 문자를 대문자로 쓰라고 추천하는 블로그도 봐서 그렇게 써오고 있었다. type 앞에 이모지를 넣기도 하고 type을 더 세분화해서 쓰기도 한다. 나도 그동안 몇 개 블로그를 참고해 쓰고 있었는데 일관되게 작성하기 위해 위에 작성한 방법만을 사용해야겠다. 원래 있는 git repository 제외하고 새로 만드는 repository에 일관된 commit message convention을 잘 적용해 보겠다!

 

 

참고

https://github.com/nhn/tui.editor/blob/master/docs/COMMIT_MESSAGE_CONVENTION.md#commit-message-convention

https://stackoverflow.com/questions/61262376/questions-about-conventional-commit-messages-in-git

https://blog.stackademic.com/mastering-git-the-power-of-conventional-commit-messages-1bfbd1cae2c2

https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue