목차
커밋(Commit)이란
Git에서 버전을 관리하는 방식은 변경 사항을 시간 순서대로 저장해두는 것이다. 이 변경 사항을 저장하는 것을 커밋이라고 한다. 어떤 작업을 한 뒤 변경한 것을 기록할 때 커밋을 한다.
커밋 메시지가 중요한 이유
이전 포스트에서도 작성했듯 버전 관리에서 가장 중요한 것은 무엇이 어떻게 변했는지 알 수 있어야 한다는 것이다. Git에서 파일의 변경을 커밋 단위로 저장되기 때문에 이 변경 내역을 알려주는 커밋 메시지를 잘 작성하는 것은 중요하다.
좋지 않은 커밋 메시지의 예시
이미 프로그래밍을 좀 해보신 분은 한다면 대체 누가 저렇게 커밋을 썼냐고 생각하시겠다. 이것은 이 글을 쓰는 본인이 실제로 작성한 커밋이다. 딱 봐도 문제가 많은 커밋 메시지로 보인다. 우선 어느곳에 어떤 것이 수정되었는지 정확하게 알 수 없다. 또 같은 이름의 커밋 메시지가 의미 없이 5개나 있다. 저 커밋을 작성할 당시에는 이게 문제가 있다는 것을 알지 못했다. 늘 혼자 프로그래밍했고 저 메시지만 봐도 나는 이해할 수 있기 때문이었다. 여기서 중요한 것은 내가 이해할 수 있는 것이 아닌 나만 이해할 수 있다는 것이 문제가 된다. 그리고 저렇게 애매하게 적어두면 시간이 지나면서 나도 이해할 수 없는 메시지가 돼버린다. 결국 내가 이해 못 하는 메시지는 남들도 이해하지 못한다.
커밋 메시지의 컨벤션
커밋 메시지의 컨벤션을 지켜야 하는 이유는 무엇일까? 다른 사람의 커밋 메시지를 빠르고 정확하게 이해하기 위해서이다. 공통의 커밋 메시지 컨벤션이 없다면 A라는 기능을 추가할 때 누구는 "A기능 추가"라고 쓰고 누구는 "add feature A"라고 적을 수도 있고 누군가는 "feat: A"라고 적을 수도 있을 것이다. 말만 통하면 되는 게 아닌가? 라고 생각할 수도 있겠지만, 아마 코딩 컨벤션을 지키는 것과 같은 이유일 것 같다. 많은 사람이 각자의 생각으로 커밋 메시지를 적으면 서로 간에 오해가 생길 수 있고 서로의 커밋을 이해하는 시간이 길어질 것이다. 자연스럽게 작업의 속도도 느려질 것이다.
- AngularJS Git Commit Message Conventions
- Udacity Git Commit Message Style Guide
- Conventional Commits
외에도 참 많은 컨벤션이 있는 것 같다. 팀에서 잘 합의한다면 어느 것을 써야 한다는 정답은 없는 것 같다.
직접 적용해 보자
❗사실 저도 아직 공부하고 있어서 정확하지는 않습니다. 참고만 해주세요!
AngularJS Commit Message Conventions를 예로 들어 몇 가지를 적용해 볼 것이다.
이 커밋 메시지 컨벤션을 적용하는 git을 몇 가지 찾아보았다. 이해가 안 간다면 이곳에서 수많은 예시를 보며 공부해봐도 좋을 것 같다.
(사실 나도 보면서 하는 중이다.. 내가 쓴 커밋 메시지가 제대로 쓴 건지 아닌지.........)
커밋 메시지 형식
<type>(<scope>): <subject> => 제목(간단 요약)
<BLANK LINE> => 빈칸
<body> => 내용
<BLANK LINE> => 빈칸
<footer> => 주요 변경 사항, 이슈 해결 사항첫 줄에 변경 내용을 한 줄로 요약한다. 자세한 변경 내용은 <body>에 적는다. 주요 변경 사항이나 이슈 해결 사항은 <footer>에 적는다. 이때 각각의 구간을 빈칸으로 구분한다. 특히 제목과 내용은 꼭 한 줄을 구분해야 한다.
제목이 가장 중요하니 제목에 대해 조금 더 보겠다.
제목 줄 (subject line)
<type>: 변경 사항의 특징에 따라 적는다.<scope>: 변경이 된 위치를 적는다.<subject>: 변경 내용을 간단하게 요약해서 적는다.
<type> 항목
- feat (feature) : 기능 추가/수정 등
- fix (bug fix) : 버그 수정
- docs (documentation) : 문서 수정
- style (formatting, missing semi colons, …) : 스타일 변경 (형식, 세미콜론 누락 등)
- refactor : 리팩토링
- test (when adding missing tests) : 테스트
- chore (maintain) : 빌드, 패키지 관련 (업데이트 등)
<scope> 항목
변경된 클래스, 메소드의 이름을 적는다. 사용한 패키지 버전이 업데이트된다면 어떤 패키지인지 적거나 README.md를 수정한다면 README.md를 적으면 될 것 같다. 때때로 쓰지 않는 경우도 있는 것 같다.
<subject> 항목
주의할 점:
- 첫 글자를 소문자로 쓴다
- 마지막에
.을 쓰지 않는다. - 명령형으로 쓰고, 현재형으로 적는다. (change(O) → changed(X), changes(X))
변경 사항을 간단하게 한줄로 요약해서 적는다.
적용해보기
Computer라는 클래스에서 랜덤한 숫자를 생성하는 기능을 추가했다면 feat(Computer): generate random number 라고 쓸 수 있을 것이다.
사용하고 있는 플로그인의 버전을 최신 버전으로 업데이트 한다면 chore(plugin): update dependency 와 같이 적을 수 있을 것이다. 여러 플러그인을 동시에 업데이트 할 때는 다음처럼 적을 수 있을 것 같다. A plugin을 최신으로 업데이트, B plugin은 1.2.3 버전으로 업데이트 한다면:
chore(plugin): update dependency
- update plugin A to the latest
- update plugin B to 1.2.3개인적인 이야기
사실 커밋 메시지 컨벤션은 정답이 있는 건 아닌 것 같다. 컨벤션에 큰 틀을 맞춰 지키면서 <subject>부분이나 <body>부분 등은 같이 일하는 동료들과 합의하여서 적으면 될 것 같다.
많은 개발자가 변수명을 짓는 것처럼 이름 짓는걸 어려워한다고 한다. 나에게 커밋 메시지도 비슷한 느낌이었다. 그래서 첫 시작은 아무런 규칙 없이 한글로 그때그때 변경한 내용을 적어 커밋을 작성했다.
하지만 얼마 되지 않아 내가 봐도 이해가 되지 않는 문제가 발생하면서 커밋에 대해 공부했던 기억이 있다. 그 당시 여러 블로그를 보면서 느낀 점은 "꼭 어떻게 해야 하는 건 아니지만 적어도 이렇게는 작성해주세요." 하는 느낌이었다.
위에서 AngularJS Git Commit Message Conventions에 대해 예시를 들면서 네이버에 오픈소스를 예시로 들었지만 모든 레포지토리에서 그 컨벤션을 쓰는건 아니다.
예를 들어 위 레포지토리는 다른 컨벤션을 이용하거나 아예 규칙이 없기도 하다. 하지만 공통으로 하는 것은 "내가 무엇을 했고", "어느 것을 고쳤다"가 있다는 것이다. 그리고 영어로 썼다는 것정도.. 그래서 미리 연습한다는 생각으로 나홀로 하는 프로젝트에서도 추가되는 건 Add를 쓴다. 변경되는 것은 Change를 쓴다. 삭제는 Remove를 쓴다 와 같이 나름대로 규칙을 정하고 커밋 메시지를 작성했다. 그래서 지금은 이전보다는 커밋 메시지를 보고 어떤 내용인지 파악하는 게 쉬워진 것 같다. 다른 사람이 내 코드를 본적도 내 커밋 메시지를 본적도 없다보니 나만의 착각일 수도 있지만..
현재는 우아한테크코스 4기에 지원해서 프리코스를 진행하고 있다. 미션을 하면서 지켜야 할 것 중 커밋 메시지 컨벤션을 지키라는 것이었다. 아마 이런 고민을 하지 않았었다면 구현하는 시간의 몇 배를 써가면서 커밋 메시지 작성에 소모했을 것 같다. 하지만 컨벤션의 존재 여부를 몰라 나만의 기준으로 작성했었던 걸 보면 여전히 많이 부족한 것 같고 더 열심히 공부해야 할 것 같다.
