[Git] 양질의 commit 남기기

소규모 개인 프로젝트같은 경우는 상관없을 수 있지만 협업 프로젝트, 거기다 규모가 조금 있다면 github repository에 다량의 commit이 쌓이게 된다. 이럴 때 commit message와 commit의 내용이 중구난방이라면 commit history관리가 안되는 문제가 발생하고 이로인해 유지보수 및 버그 원인추적에 어려움을 겪을 수 있다

 

commit의 양질의 내용을 담는법과 message규칙의 예를 들며 정리해보겠다

 

- 하나의 작업 혹은 기능이 완성된 commit일 것

작은 단위로 많은 commit을 남기는 것이 좋은 것이라고 들어본 적이 있을것이다 하지만 너무 작게 쪼개면 그건 하나의 버전이라기보단

그냥 작업 내용 백업에 가깝다고 생각한다. 최소단위로 하나의 method, class 등 기능이나 버그 수정같은 작업을 단위로 삼아서 commit하는것이 해당 commit의 내용을 파악하기에 적합하다

 

- 다른 기능에 영향을 끼치는 버그가 없는 완성된 commit일 것

작업 혹은 기능이 버그없이 잘 동작하는지 테스트까지 마친 상태의 코드가 commit되어야 한다. 또한 해당 기능뿐만 아니라 그 commit으로 인해 다른 기능에는 영향을 미치는게 없는지 전체적으로 해당 commit으로 인해 버그가 발생하지는 않았는지 테스트 후에 commit을 진행해야 한다

 

- commit message는 간결하면서 규칙을 정할 것

Conventional Commit이라는 commit message 규칙이 존재한다 이 규칙에서는 <type>(<scope>): <subject>의 형식을 따르게 되고 하나씩 설명하면 type은 commit의 종류를, scope는 commit이 영향을 미친 범위를, subject는 간략한 설명이다 예를 들면

feat(UesrLogin): Add sns login 같이 작성 가능하고 해석하면 유저로그인 부분에 소셜로그인이 추가되었다는 뜻이다

표로 정리하면 이렇다

type	설명
feat	기능 개발과 관련
docs	주석/ReadMe 등 문서화 관련
test	테스트 관련
fix	버그나 typo등을 수정한 사항 관련
chore	코드와 관련이 없는 내용들을 수정할 때 (License 등)
ci	CI/CD 등과 관련한 작업을 수행할 때

이러한 Conventional Commit을 사용하면 commit message에서 원하는 부분을 추출해서 자동으로 문서화 할 수 있지만

이 규칙은 강제되거나 엄격한 형태의 규칙은 아니다

규칙을 커스터마이징해도 되고 속한 팀의 특성에 따라 자체적인 규칙을 만들어도 된다 하나의 가이드 라인으로 받아드리면 되는 부분이고 가장 좋은 방법은 팀 내에 가장 어울리는 규칙을 만드는것이다