좋은 커밋 메시지 작성법

커밋을 세부 기능단위로 작성해야 하는 이유는 아래 2가지 라고 생각한다.

 

• 에러가 발생했을 때 세부 기능단위로 돌아갈 수 있다.
• 내가 지금 어느 부분을 코딩하고 있는지 명확하게 알 수 있다.

2가지 목적을 달성하기 위해서는 커밋 메시지를 통해서 커밋을 이해하는데 도움을 줘야 한다.

커밋 메시지를 잘 작성하기 위해서 했던 고민들과 내가 생각한 효율적인 커밋 메시지 작성법을 공유한다.

---

커밋 메시지 패턴에 대한 고민

git을 처음배우고 사용할 때는 커밋 메시지의 중요성을 몰랐다. 그래서 Ctrl+s를 누르듯이 그날 하루의 코딩을 다하고 집에 가기 전에 commit을 하였다. 하지만 협업을 하면서 커밋 메시지의 중요성을 알게되었고 어떻게 하면 좋은 커밋 메시지를 작성할 수 있는지 공부하였다.

 

최근까지 아래 블로그 에서 소개해준 방식으로 커밋 메시지를 작성하였다.

 

https://dejavuhyo.github.io/posts/patterns-for-writing-better-git-commit-messages/

더 나은 Git 커밋 메시지 작성 패턴

 

위 방식을 사용하다 보니 몇가지 불편한 점이 생겼다.

 

첫번째로 scope를 작성하는 것이 어려웠다.

선택사항이긴 하지만 변경되는 부분을 명시하면 좋을 것 같아서 커밋 메시지의 제목에 작성하였다. 하지만 클래스 분리와 같이 여러 객체에 영향을 미치는 경우에는 모든 변경된 부분을 명시하는것이 가독성을 떨어뜨렸다. 그래서 메시지의 내용 부분에 어떤것을 바꾸었는지 적기로 하였다.

한 커밋에서는 하나의 변경사항만 다루도록 여러개의 커밋으로 나누면 해결된다고 생각 할 수 도 있다. 하지만 한 부분만 변경하고 나머지 부분은 그대로 둬서 오류가 발생하는 코드를 커밋하는 것은 의미가 없다. 오류가 나는 코드를 기록하고 공유하는 것은 협업을 방해하는 커밋이라고 생각한다.

 

두번째로 영어로 작성하는 것이 어려웠다.(영어를 못하는건 절대 아니다) 

영어로 작성하다 보니 한국어로 작성하는 것 보다 의미 전달이 명확하지 않았다. 물론 외국인과 협업하는 경우에는 영어로 작성해야 한다. 하지만, 그 외 경우에는 한국어로 작성하는 것이 의미 전달도 명확하고 읽는 사람도 커밋을 쉽게 이해할 수 있을 것이다.

---

좋은 커밋 메시지

[타입] : [제목]

[내용]

[이슈 언급]

예시:

feat: Computer 객체에서 Answer 객체를 분리

Answer 객체 내부에서 정답에 대한 유효성 검사를 하기 위해 Computer에서 Answer 객체를 분리하였습니다.

Close: #1

 

타입

커밋 타입에는 아래와 같은 것들이 있다

타입	설명
feat	새로운 기능 추가
refactor	코드 리팩토링
docs	Readme.md와 같은 문서 수정
style	코드를 정리
chore	설정파일 변경
test	테스트 코드 변경
fix	버그 수정
design	사용자 UI 디자인 변경
perf	성능을 향상시키는 코드 변경
revert	커밋 되돌리기
rename	파일 혹은 폴더명만 변경 또는 이동
remove	파일이나 폴더를 삭제

프로젝트를 하면서 실제로 자주 썼던 커밋 메시지 위주로 정리하였다. 위에 포함되지 않는 커밋 타입은 필요할 때 추가하여 기록할 것이다.

 

내용을 보면서 refactor와 style의 차이는 무엇인지 궁금하였다. 둘을 어떻게 구분할 수 있을까?

• refactor: 중복된 코드 제거 / 클래스를 분리 / 함수 인수 재구성 등과 같은 작업
• style: 공백과 들여쓰기 수정 / 변수이름 변경

명확하게 말로 설명하긴 어렵지만, 예를 들어서 보니 어떻게 구분하는지 알 것 같다. 둘 다 코드를 깔끔하게 만드는 일이지만 전체적인 형식을 바꾸는 것은 refactor로, 가독성을 위한 작은 변경은 style로 작성한다고 생각하면 된다.

 

커밋 메시지의 타입이 나누어져 있다는 것은 반대로 저런 변경사항이 있을 때 커밋을 하라는 의미이다. 이제까지 파일을 옮기는 것과 같은 단순한 작업은 커밋으로 따로 구분하지 않았다. 사실 파일의 이동은 feat나 refactor를 수행하면서 하는 경우가 많기 때문에 따로 분리하기가 어려웠던 것 같다. 가능하다면 이전에 하던 작업을 다 한 후에 파일을 옮기는게 좋겠다. 만약 이게 불가능 하다면 feat+remove와 같이 커밋 메시지를 작성하는 것도 방법이지만 가독성의 측면에서 추천하지 않는다.

 

 

제목

• 마지막에는 .을 찍지 않는다
• 50자를 넘기지 않는다
• 명령문의 형태로 작성한다

위의 조건들 모두 커밋의 내용을 명확하게 전달하기 위한 규칙들이고 대부분의 사람들이 공유하는 규칙이기 때문에 그대로 따르면 된다.

 

 

내용

앞서 제목에서는 어떻게 바꾸었는지를 설명했다면, 내용에서는 왜 바꾸었는지에 대하여 설명해야 한다. 만일 설명해야하는 내용이 72자 보다 길다면 72자 마다 줄바꿈을 한다. 

 

 

이슈 언급

이슈를 변경하는 상황에 작성하면 된다. 주로 Close(이슈 종료), Fixes(이슈 수정), Resolves(이슈 해결), Ref(이슈 참고)를 사용하지만, 이제까지 프로젝트를 하면서 Close만 항상 사용하였다.

 

---

마무리

좋은 커밋메시지란 커밋의 내용을 명확하게 전달하는 것이라고 생각한다. 나만 이해하는 커밋은 좋은 커밋이 아니다. 커밋 메시지만 보고도 다른 사람들이 커밋의 내용을 이해할 수 있도록 간결하고 명확하게 작성해야 한다. 이를 위해서는 많은 사람들이 공유하는 커밋 메시지 작성법을 따르는 것이 좋은 것 같다.

 

앞으로

위에서 정한 커밋 메시지 패턴을 적용하여 커밋 메시지를 작성할 것 이다. 피드백할 내용이 있다면 편하게 피드백을 해주면 좋을 것 같다. 계속해서 내용을 수정하면서 좋은 커밋 메시지를 저장하는 데이터베이스로 활용하고 싶다.