처음으로 체계적인 협업 프로젝트를 진행하면서 Git의 Commit Convention에 대해서 고민하는 일이 있었다.

Git을 활용해서 제대로 협업하는 경우는 처음이었기 때문에, 기존에 협업 경험이 있는 분의 주도하에 commitzen을 이용하자는 제안이 나왔다.

그래서 commitzen에 대해서 이해하고 간단하게 사용법을 알아 보려고 한다.

1. Convention

세상에는 표준(또는 규칙)이라는 것이 존재한다. 그것은 세계 각지의 사람들이 공식적으로 모여 발표되기도 하거나 암묵적으로 사용되기도 한다.

Convention이란 쉽게 직역하면 "관례"정도라고 표현할 수 있겠다.

개발 세계에서도 여러 분야에 convention을 두고 사용한다. 예를 들어 보통 Java 개발자는 Camel case Naming convention을 적용하여 변수를 작성한다.

이러한 convention은 강제되는 것은 아니지만, 이미 수많은 경험이 쌓여서 나온 산출물이기 때문에 개인 그룹이 임의로 정하는 방식 보다 체계적이고 깔끔하며, 널리 널리 공용적으로 사용된다면 일관적으로 어디서나 적응할 수 있다는 장점이 있다.

그래서 개발을 하다 보면 여러 convention의 규칙을 지키며 개발하게 된다.

2. Commit (Message) Convention

Git에도 개발자들 사이에서 암묵적으로 사용되는 commit (message) convention이 존재한다.

commit을 할 때에 작성하는 메시지의 관례를 만들어 사용하고 있는 것이다.

기본적인 구조는 아래와 같다.

type(스코프): Subject - 제목
body - 내용
footer - 꼬리말

1. type

type은 아래와 같은 종류가 있다. (대소문자 구분)

feat : 새로운 기능 추가

fix : 버그 수정

design : CCS와 같은 사용자UI 디자인 변경

!BREAKING CHANGE : 커다란 API 변경

!HOTFIX : 급하게 치명적인 버그를 고치는 경우

style : 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우

refactor : 코드 리팩토링 시

comment : 주석 추가 및 변경

docs : 문서 수정

test : 테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음

chore : 빌드 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음

rename : 파일이나 폴더명을 수정하거나 옮기는 경우

remove : 파일을 삭제하는 작업만 수행한 경우

1-1 스코프

커밋이 내용이 어디서 발생한 것인지 부가적으로 작성하여 알리는 것이다. 반드시 작성할 필요는 없다.

1-2 Subject

Subject는 제목에 해당된다고 볼 수 있다.

Subject 작성 규칙.

1. Subject는 50글자 이내로 작성.

2. 첫글자는 대문자로 작성.

3. 특수기호를 사용하지 않음.

4. 영문으로 작성하는 경우 동사를 가장 앞에 명령어로 작성.

5. 과거시제를 사용하지 않음.

6. 간결하게 요점만 적는다.

2. Body

Body는 본문에 해당한다고 볼 수 있다.

Subject 작성 규칙.

1. 72이내로 작성. 넘어가는 경우 문단(엔터 두 번)으로 나누어 작성

2. 최대한 상세히 작성. ( 코드 변경의 이유를 명확히 작성 -> 무엇을, 왜 변경했는가 )

3. Footer

footer는 부가적인 내용을 담는 부분이라고 보면 된다. 이슈 트래커 ID를 명시하고 싶은 경우에 작성한다. (선택사항)

이슈 트래커란 프로젝트의 이슈를 추적하고 관리하는 시스템을 말하며 Github에서는 Respoitory의 Issues가 여기에 해당한다.

이슈 트래커 ID는 이 Issues에 보고된 이슈들을 식별하는 ID이다. 이슈에 들어가 보면 "#123" 이런형태로 쓰여 있다.

유형: #ID -> 예 ( Resolves: #123 )

으로 작성한다.

여러 개의 이슈번호는 쉼표(,)로 구분한다.

이슈 트래커 유형 아래와 같다.

Fixes : 이슈 수정 중

Resolves : 이슈를 해결했을 때

Ref : 참고할 이슈가 있을 때

Related to : 해당 커밋과 관련된 이슈번호 (아직 해결되지 않은 경우)

See Also : 그 외 참고할 사항들

3. Commitzen

commit convention을 제대로 이해하고 있고, 그렇게 작성하는 데에 무리가 없다면 다행이지만 모든 convention 규칙을 모두 외우고 있기는 어렵고 모르면 매번 검색해야 하는 번거로움이 있다.

이러한 문제점을 조금이나마 해결하기 위해 commit convention을 기반으로 커밋 메시지 작성을 자동화 시켜 주는 Commitzen이라는 도구가 나왔다.

Commitzen은 커스텀 기능도 지원하기 때문에 사용법을 잘 숙지한다면 유용하게 사용할 수도 있을 것 같다.

( 필자는 아직 사용해 본 경험이 없기 때문에, 추후 사용하게 된다면 따로 정리해 볼 생각이다. )

이것은 특정 도구는 아니고 그냥 .gitmessage.txt 파일을 만들어서 "git config commit.template" 명령어를 통해 적용 가능하다.

자동화 기능을 제공하는 것은 아니지만, 사용법이 간단하기 때문에 매번 검색해야 하는 번거로움이나 특정 템플릿 형식을 직접 만들어 사용하고 싶다면 나쁘지 않은 방법이라고 생각한다.

정리

처음으로 제대로 된 협업을 하려다 보니, 몰랐던 내용들이 많이 생기기도 했고 반대로 새롭게 알게 된 내용도 많았다.

커밋 메시지는 어떻게 보면 사소한 내용일 수도 있지만 협업을 하는 사람들과 적절한 규칙을 정해 놓아야 서로 이해하기 쉽고 불협화음이 생기지 않을 것이다.

앞으로 커밋 메시지를 작성할 때에는 위의 규칙을 지키며 작성해 봐야겠다.