04. 커밋 생성, 커밋 메시지 작성 가이드라인

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

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

(1) 커밋을 한 사용자 아이디 

(2) 커밋한 날짜, 시간

(3) 커밋 메시지

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

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

그 규칙들은 회사마다 전부 다르겠죠? 그래도 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반론적인 가이드라인은 있습니다. 잠깐 살펴보자면 다음과 같습니다.

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

(1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.

이전 영상에서 커밋 메시지를 남길 때 봤던 장면인데 기억나시나요? 지금 1번이 커밋 메시지의 제목(title), 2번이 커밋 메시지의 상세 내용(body)이라고 생각하시면 됩니다. 뭔가 상세한 설명이 필요한 커밋인 경우에는 커밋 메시지 한 줄보다는 이런 식으로 제목과 상세 내용으로 구분해서 적어주면 좋은데요. 이럴 때 제목과 상세 내용 사이에 한 줄을 띄워놓아야 나중에 커밋 메시지를 볼 때 좀더 편하게 볼 수 있습니다. 그리고 이렇게 비어있는 한 줄을 두는 것이 Git에서 공식적으로 권장하는 사항(예를 들어, 특정 명령어가 이 한 줄을 기준으로 제목과 상세 내용을 구분해서 사용한다고 합니다)이기도 하니까 꼭 지켜주세요.

(2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.

(3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.

(4) 커밋 메시지의 제목은 명령조로 작성하세요.(Fix it / Fixed it / Fixes it)

(5) 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.

• 왜 커밋을 했는지
• 어떤 문제가 있었고
• 적용한 해결책이 어떤 효과를 가지는지

(6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요.

어떤가요? 이런 것들을 신경쓰면서 커밋 메시지를 남겨야 남들이 여러분이 한 커밋에 대해 더 잘 이해할 수 있겠죠?

그런데 사실 커밋 메시지를 작성하는 방법뿐만 아니라 커밋을 남기는 것 자체에 관해서도 일종의 가이드라인이 있습니다. 그것들을 정리해보면 아래와 같은데요.

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

(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다. 

이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻입니다. 예를 들어 여러분이 A라는 파일에서 기존 함수를 3개 삭제하고, B라는 파일에서 기존 함수 2개를 삭제, C라는 파일에서 기존 함수를 1개 삭제했다고 합시다. 그 다음 프로그램을 실행해봤는데 오류가 생겼다면 과연 A, B, C 파일 중 무엇때문에 문제가 생긴건지 일일이 확인해보지 않는 이상 알 수 없겠죠? 이처럼 다양한 종류의 수정을 다 하고나서야 커밋을 하면 바로 그 다음에 프로그램에 문제가 생겼을 때 그 원인을 파악하는데 시간이 더 오래 걸립니다. 그리고 이렇게 하면 커밋 간의 독립성이 사라져서 나중에 프로젝트의 이력을 파악하는 일도 어려워지기도 하죠.

하지만 어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있습니다. 회사의 규칙에 따라 다를 수도 있구요. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야합니다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 합니다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아닙니다. 과거의 커밋이라도

• 과거 버전의 프로그램을 사용해야하거나
• 과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나
• 아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있습니다.

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

자, 이때까지 커밋에 관한 가이드라인들을 살펴봤습니다. 사실 이런 가이드라인은 회사마다 다를 수 있고, 절대적인 규칙이 있는 것도 아닙니다. 어떤 경우든지 본인이 다니는 회사의 가이드라인을 잘 준수하는 것이 좋겠죠? 혹시 가이드라인이 없다고 할지라도

• 나중에 다시 봤을 때 이해하는데 어려움이 없도록
• 다른 동료 개발자와 협업하는 데 방해가 되지 않도록

커밋을 남기고, 그 때마다 커밋 메시지를 잘 작성하는 것이 중요합니다.