섭섭한 개발일지

[Git] Git Commit Convention 본문

협업/Git

[Git] Git Commit Convention

Seop 2022. 12. 6. 11:58

 

우테코를 진행하며 git 컨벤션을 지키는 요구사항이 있었습니다.

이전까지는 혼자서 하다보니 이러한 컨벤션을 지키지 않고 나만 알아볼 수 있는 commit 메세지를 작성을 하였는데

협업을 하기 위해서는 이러한 컨벤션(규칙)을 지켜야 한다는 것을 뒤늦게 깨달았습니다..

 

그렇다면 어떤 차이가 있는지와 규칙이 어떻게 되는지 알아보겠습니다.

 

컨벤션을 지키기 전 Git Commit Message

 

깃 컨벤션 적용 전

 

Git 컨벤션을 따라 작성한 Commit Message

 

깃 컨벤션 적용 (저도 규칙을 지키지 않은 부분이 있었네요..!)

 

 

Git 컨벤션이란?

 

협업을 위해 커밋 메세지를 작성할 때 일관성 있게 작성할 수 있도록 규칙을 세운 것이다.

 

 

Commit Msg 규칙

 

커밋 메세지는 기본적으로 제목, 본문, 꼬리말로 구성이 된다.

type: subject (제목)

body (본문)

footer (꼬리말)

type :

어떠한 작업을 했는지 작성합니다. type 은 정해져 있는 태그가 있기에 아래에서 알아보도록 하겠습니다.

type 뒤에는 띄어쓰기 없이 ':' 를 사용하고 제목 사이에 띄어쓰기를 해줍니다.

 

subject :

제목을 작성합니다. 어떠한 작업을 했는지 간단 명료하게 작성을 해주는 것이 포인트입니다. 

최대 50자 이내로 작성을 하며 동사 원형으로 시작을 하고 영어일 경우 첫 글자는 대문자로 작성해주고 마침표를 찍지 않습니다.

 

body :

subject에 작성한 것만으로 설명이 되지 않는 경우 작성을 해줍니다. body에 작성하는 문구는 "무엇을 왜" 하였는지에 대하여 작성을 해주는 것이 원칙이며 72자를 넘기지 않습니다.

 

footer :

필수가 아니며 issue tracker 를 명시하고자 할 때 작성합니다.

 

 

 

메세지 작성 예시는 type 태그를 알아본 후에 보도록 하겠습니다.

 

 

Commit type tag

 

태그 설명
feat 신규 기능 추가
fix 버그 수정
style 코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우
design css , ui 디자인 수정
comment 주석 추가 및 수정
docs 문서 수정
refactor 코드 리팩토링
test 테스트 코드 추가 및 수정
rename 파일명, 폴더명 수정 또는 이동
remove 파일 삭제
chore 빌드 수정, 패키지 매니저 수정
build 빌드 관련 파일 수정
ci CI 설정 파일 수정
perf 성능 개선

 

태그는 첫 글자를 대소문자 구분에 대한 의견이 있는 것 같습니다.

저는 처음 배울 때 소문자로 배워 소문자로 작성을 하고 있습니다 :)

 

 

Commit Message Example

 

예시는 유다시티에서 제공하는 예시를 사용하겠습니다.

 

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

 

유다시티 깃 컨벤션 가이드 보러가기

 

Udacity Nanodegree Style Guide

Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the

udacity.github.io

 

Other

 

커밋 메세지에서 사용할 수 있는 이모지들도 있고 위에 작성해둔 정보 외에 다양한 정보가 있으니

한번 검색을 해보시는 것도 좋을 것 같습니다 :)

 

 

'협업 > Git' 카테고리의 다른 글

Git 개념 정리  (0) 2023.11.03
Comments