커밋 메시지 작성하기

커밋(commit)은 Git에서 가장 핵심적인 개념이다. 커밋은 staging area의 현 상태를 그대로 하나의 버전으로 남기는 작업, 또는 그 결과물을 가리킨다.

커밋에는 크게 다음과 같은 3가지 정보가 있다.

(1) 커밋을 한 사용자 아이디
(2) 커밋한 날짜, 시간
(3) 커밋 메시지

특정 프로젝트 디렉토리가 어떻게 변해왔는지를 한 눈에 잘 파악하기 위해서는 커밋의 이런 정보들이 아주 중요하다. 그런데 (1), (2)는 커밋을 할 때 Git에서 자동으로 기록해주지만, (3) 커밋 메시지는 커밋을 하는 사람이 매번 직접 작성하는 것이기 때문에 사람마다 그 분량이나 스타일이 제각각일 수 있다.

개인 프로젝트의 경우에는 커밋 메시지를 어떻게 작성하든 큰 상관이 없을 수 있지만, 회사에서 여러 명이 참여하는 프로젝트의 경우에는 이 커밋 메시지가 아주 중요하다. 그래서 커밋 메시지를 어떻게 작성해야하는지에 대한 규칙이 정해져있는 경우가 많은데,
그 규칙들은 회사마다 전부 다르다. 그래서 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반적인 가이드라인이 있다.

1. 커밋 메시지 작성 가이드 라인

• 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두기. (git에서 공식적으로 권장하는 사항)
• 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 말자.
• 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성해라.
• 커밋 메시지의 제목은 명령조로 작성해라.(Fix it / Fixed it / Fixes it)
• 커밋의 상세 내용에는 [①왜 커밋을 했는지 ②어떤 문제가 있었는지 ③적용한 해결책이 어떤 효과를 가져오는지] 를 적으면 좋다.
• 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 적어라.

2. 커밋할 때 알아야할 가이드라인

(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 한다.

다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽다. 이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻이다.
어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있고, 회사의 규칙에 따라 다를 수도 있다. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야한다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하자. 

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 한다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아니기 때문에 과거의 커밋이라도 ①과거 버전의 프로그램을 사용해야하거나 ②과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나 ③아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있다.

따라서 매 커밋의 코드들은 항상 정상 실행되는 상태의 코드여야 한다. 그렇지 않으면 나중에 그 커밋을 위와 같은 용도로 사용하려고 할 때 문제가 생길 수 있다. 그리고 협업하는 상황을 생각해봐도 내가 남긴 커밋을 동료 개발자가 실행해봤는데 에러가 나고 실행이 되지 않는다면 좀 민망할 수 있다. 그래서 커밋을 하기 전에 프로그램이 정상 실행되는지 점검하고 커밋하는 것이 좋다.

혹시 가이드라인이 없다고 할지라도 나중에 다시 봤을 때 이해하는데 어려움이 없도록, 다른 동료 개발자와 협업하는 데 방해가 되지 않도록 커밋을 남기고, 그때마다 커밋 메시지를 잘 작성하는 것이 중요하다.