협업을 위한 Commit Convention 정의하기

 

협업 프로젝트를 진행하다 보면 다양한 스타일의 커밋 메시지로 인해 커뮤니케이션에 어려움을 겪는 경우가 많습니다. 특히 팀원이 많아질수록 코드뿐만 아니라 커뮤니케이션 방식에도 일관성이 필요합니다.

이 글에서는 협업을 효율적으로 하기 위해 현재 제가 진행 중인 프로젝트 팀에서 사용 중인 Commit Convention을 정리해 보았습니다.

 

Commit Convention

저희 팀의 커밋 컨벤션은 Conventional Commits를 참고하여 결정했습니다.

 

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

 

Convetional Commits는 위와 같은 커멧 메시지 구조를 정의하고 있습니다.

 

저희 팀은 커밋 헤더만을 채택하고, optional한 body와 footer는 사용하지 않기로 하였습니다.

 

🛠️ 커밋 작성 원칙

• 한 커밋에는 한 가지 의미만 담는다.
• 기능이 작게 쪼개지지 않았다면, 더 세분화할 수 있는 방법이 없는지 고민해 본다.
• 커밋 헤더만 보더라도 무엇이 변경되었는지 파악할 수 있도록 작성한다.

 

❌  body와 footer를 사용하지 않는 이유

저희 팀은 커밋의 바디나 푸터보다는 PR을 통해 기능 설명을 자세히 남기기로 합의했습니다.
그 이유는 다음과 같습니다:

• 커밋 헤더만으로도 충분히 의미를 전달할 수 있는 구조로 작성하면, 커밋 히스토리를 읽기 쉬움
• 바디와 푸터를 무리하게 작성하기보다, PR에서 문맥과 의도를 충분히 설명하는 것이 효율적
• 커밋을 작게 쪼개어 기록함으로써 변경 이력을 추적하기 쉬워짐

 

✅ 커밋 타입 예시

Feat	새로운 기능 추가
Fix	버그 수정
Docs	문서 수정
Style	코드 포맷팅 (세미콜론 등)
Refactor	코드 리팩토링 (기능 변화 없음)
Test	테스트 코드 추가 또는 수정
chore	기타 변경사항 (빌드, 설정 파일 등)

 

 

✅ 커밋 메시지 예시

 

위처럼 커밋 컨벤션을 적용하여, 어떤 커밋이 어떤 의도를 가지고 작성되었는지 명확해졌고. Git 로그를 통해 변경사항을 구조적으로 파악하는 것이 더 수월해졌습니다.