[Git] git 커밋 컨벤션 (Git Commit Message Convention)
** 개인 기록용
현재 일하고 있는 팀에 커밋 컨벤션이 없다.
그러다보니 사람들이 커밋시에 보통 작업번호를 적고 끝나는 경우가 많은데 그러다보니 커밋 로그로 변경사항을 확인할때 어려움이 많다. 작업자에게 찾아가서 이때 왜 이렇게 작업을 했는지 히스토리를 여쭈어봐야한다. 그 분이 기억을 잘 하고계시면 좋겠지만 안그런경우도 많기때문에 커밋 컨벤션은 필요하다.
우테캠pro과정을 진행하는동안 커밋컨벤션(AngularJS Git Commit Message Conventions)에 맞춰 커밋을 하는게 규칙이었다. 기능단위로 쪼개서 커밋하기와 컨벤션에 맞게 로그를 남기기를 실천하다보니까 확실히 도움이 많이 된다는걸 느꼈다.(로그가 정말 보기 좋아진다..진짜 진짜로..) 내가 만든 코드도 나중에 보면 기억이 하나도 안나기에..😂
그래서 회사 업무를 할때도 보편적인 컨벤션대로 커밋 메시지를 쓰기 시작했다. 나름대로 우리팀에 맞는 컨벤션이 어떻게 될까? 라는 고민을 하면서 여러가지 시도를 했고 조만간 팀원들에게 공유를 할 생각이다. 🔥
git 커밋 메시지를 잘 적으면 아래와 같은 이점이 있다.
- 더 좋은 커밋 로그 가독성
- 더 나은 협업과 리뷰 프로세스
- 더 쉬운 코드 유지보수
Message Structure
type: Subject
body
footer
커밋메시지는 보통 제목, 본문, 꼬리말로 작성한다
어떻게 변경하였는지보다 무엇을, 왜 변경했는지 적는다
Type
- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 수정
- style: 포맷팅, 세미콜론 빠졌을때, 코드 변경이 없는 수정
- refactor: 리팩토링
- test: 테스트 코드 추가, 테스트코드 리팩토링
- chore: 빌드관련 수정, 패키지 매니저 수정
위 7가지가 보편적인것 같은데 추가적으로 remove, move, rename 같은걸 사용하기도한다.
Subject
- 제목은 50자를 넘기지 않는다.
- 마침표를 붙이지 않는다.
- 과거시제를 사용하지 않는다.
- 명령어로 작성한다.
Body
- 선택사항이라 작성하지 않아도 된다.
- 부연설명이 필요할때 작성한다.
Footer
- 선택사항이라 작성하지 않아도 된다.
- issue tracker id등 ID같은걸 참조할 때 사용한다.
무엇보다 가장 중요한건 원칙을 정하고 일관성 있게 작성해야한다는 것이다.
한번 정한 원칙이 일관성있게 지켜지려면 보편적인 컨벤션이라고 따라하는게 아니라, 팀에 맞게 잘 정해져야 원칙이 지켜질 수 있다고 생각한다.
현재 팀에서 개발자들끼리 사용하는 우리팀만의 용어들이 있는데 그에 맞게 type들을 좀 추가하여 적용해볼예정이다.
컨벤션이 잘 정착하여 오래오래 잘 지켜졌으면 좋겠다 🙏
참고
https://udacity.github.io/git-styleguide/
https://doublesprogramming.tistory.com/256
AngularJS Git Commit Message Conventions
좋은 git 커밋 메시지를 작성하기 위한 7가지 약속