Commit 생성, commit message 작성 가이드라인

 

 

커밋(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) 커밋의 상세 내용에 들어가면 좋을 내용

• 왜 커밋을 했는지(why)
• 어떤 문제가 있었고(what was matter)
• 적용한 해결책이 어떤 효과를 가지는지(what has improved)

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

 

 

 

사실 커밋 메시지를 작성하는 방법뿐만 아니라 커밋을 남기는 것 자체에 관해서도 일종의 가이드라인이 있다.

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

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

이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻이다.

예를 들어 A라는 파일에서 기존 함수를 1개 삭제하고, B라는 파일에서 기존 함수 2개를 삭제, C라는 파일에서 기존 함수를 3개 삭제했다고 하면 . 그 다음 프로그램을 실행해봤는데 오류가 생겼다면 과연 A, B, C 파일 중 무엇때문에 문제가 생긴건지 일일이 확인해보지 않는 이상 알 수 없다. 이처럼 다양한 종류의 수정을 다 하고나서야 커밋을 하면 바로 그 다음에 프로그램에 문제가 생겼을 때 그 원인을 파악하는데 시간이 더 오래 걸린다. 그리고 이렇게 하면 커밋 간의 독립성이 사라져서 나중에 프로젝트의 이력을 파악하는 일도 어려워진다.

너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야한다.

 

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

나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있다.

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

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

따라서 매 커밋의 코드들은 항상 정상 실행되는 상태의 코드여야 한다.. 그렇지 않으면 나중에 그 커밋을 위와 같은 용도로 사용하려고 할 때 문제가 생길 수 있다. 따라서 커밋을 하기 전에 프로그램이 정상 실행되는지 점검하고 커밋하는 것이 좋다. 

 

사실 이런 가이드라인은 회사마다 다를 수 있고, 절대적인 규칙이 있는 것도 아니다. 어떤 경우든지 본인이 다니는 회사의 가이드라인을 잘 준수하는 것이 우선이지만, 혹시 가이드라인이 없다고 할지라도

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

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