[Git] Conventional Commit

팀에서 Conventional Commit을 도입했는데 도입 한 이유는 더 효율적인 작업과 커밋을 위해서입니다.

 

Conventional Commit 을 간단히 설명하면 정형화된 커밋 메세지를 통해 사람과  별도 프로그램 모두 쉽게 커밋 메세지를 읽게 하는 것입니다.

https://www.conventionalcommits.org/en/v1.0.0/

Conventional Commits

몇가지 예는 다음과 같습니다.

    - feat: 기능 A 개발

    - fix: 버그 B 수정

    - test: 기능 C 테스트 작성

 

위 예에서 봐도 알겠지만 쉽게 말해 가장 큰 특징은 각 커밋마다 타입이 있고 그 타입이 앞에 붙는 것입니다.

브레이킹 체인지를 나타내는 ! 등의 추가적인 규칙이 있지만 우선 타입만 붙여도 팀 생산성에 효과가 좋은 것 같습니다.

(자세한 규칙은 위 Conventional Commit 홈페이지를 참고 해 주세요.)

 

어떤 타입을 어떻게 써야 하는지가 제일 애매한데 제가 봤던 자료 중에서는 아래 문서가 각 타입을 가장 잘 설명하고 있었습니다.

https://kapeli.com/cheat_sheets/Conventional_Commits.docset/Contents/Resources/Documents/index

Conventional Commits Cheat Sheet - Kapeli

 

적용하다보니 몇 가지 공유할만한 운영상 참고사항이 있었습니다.

운영상 참고 사항1 - 각 타입에 맞게 커밋을 쪼갠다.

Conventional Commit을 적용하다보면 기능 개발과 기능 개발을 위한 테스트가 있을 때 어떻게 커밋을 해야 할 지 애매할 때가 있습니다.

 

팀마다 운영 방침을 둘 수 있지만 저희 팀의 경우 테스트와 기능 개발 코드를 별도 커밋으로 커밋하여 test, feat가 2개 커밋이 생성되도록 했습니다.

 

이렇게 하면 미리 어떤 작업을 해야 할 지에 대해 고민해보아야 하므로 조금 더 체계적으로 작업에 대해 미리 생각해볼 수 있게 됩니다.

 

운영상 참고 사항2 - husky, commitlint 등과 함께 사용

Conventional Commit만을 적용해도 좋지만 함께 작업하는 사람들에게 강제할 수 없습니다.

그래서 git 커밋 시점에 커밋 메세지를 검사할 수 있도록 husky, commitlint와 함께 사용하면 좋습니다.

 

운영상 참고 사항3 - CHANGELOG 생성 가능

CHANGELOG를 작성하는 것이 여러 측면에서 좋습니다.

https://keepachangelog.com/en/1.0.0/

Keep a Changelog

아직 팀에서 적용하지는 않았지만 Conventional Commit을 사용해 CHANGELOG도 비교적 쉽게 생성할 수 있는 것으로 보여 고려 해 보는 것도 좋습니다.

https://github.com/conventional-changelog/standard-version

GitHub - conventional-changelog/standard-version: Automate versioning and CHANGELOG generation, with semver.org and conventional