좋은 커밋은 무엇인가?

커밋 메시지란?

• 커밋 명령어는 깃 안에 staging(= 커밋으로 저장소에 기록할 수정사항을 대기상태로 만들기)을 한 이후 로컬 리포지토리(repository) 에 발생한 변화를 저장하는 데 사용됩니다.
• 커밋 옵션들
• -m : 해당 옵션은 커밋 메세지를 설정

git add static/admin/config.yml
git commit -m "Setup multiple roles for netlify-cms git gateway"

• -a or -all : 새로운 걸 포함한 모든 tracked, modified, 또는 deleted 상태의 파일들을 자동으로 커밋합니다.

git commit -a -m "Add a new role for netlify-cms git gateway"

• --amend : 해당 옵션은 현재 staged 된 변경 사항 또는 새 커밋 메세지로 마지막 커밋을 다시 작성하며 아직 원격 저장소에 푸시되지 않은 커밋에서만 실행해야 합니다.

git add .
git commit --amend -m "Update roles for netlify-cms git gateway"

왜 좋은 커밋 메세지를 써야함을 알게 되었는가?

• 기존의 프로젝트 커밋 메세지는 [FEAT], [STYLE], [FIX] 등등 앞 부분에 키워드를 붙이고, 커밋 메세지를 썼었다. 그 당시에는 그게 좋은 커밋 메세지인 줄 알았다. 그러나 시간이 지나고 다시 그 커밋 메세지만을 봤을 때 어떤 것에 대한 커밋 메세지인지 정확하게 설명이 없어 코드 리팩토링 또는 다른 기능을 추가할 때 혼란을 겪었다.

좋은 커밋 메세지를 써야하는 이유는 뭘까?

다른 개발자에게 새로운 내용이나 수정사항에 대한 배경을 소통하는 최고의 방법이면서 동시에 미래의 나에게 남겨두는 메세지 같은 것이다.

개인 혼자일 때는 시간이 지나도 나의 스타일이 녹아 있기 때문에 간단한 커밋메세지만 봐도 이해가 된다. 하지만, 여러 명이서 작업을 할 때는 무슨 메세지인지 이해하는데 시간을 허비할 수도 있다. 얼마나 시간 낭비인가...

이전의 나는 커밋 메세지를 "[FEAT]: VC에 버튼 추가 및 폴더 생성" 이렇게만 남겼다. 나는 무슨 VC인지 버튼인지 폴더를 그 순간에는 알고 있다. 시간이 지나면 모른다. 그래서 우리는 커밋을 작성할 때, VC에 대한 설명과 버튼과 폴더에 대한 추가 상세한 설명도 깃에 남겨야 한다는 것을 알게 되었다.

좋은 커밋 메세지는 어떻게 작성하는가?

좋은 커밋을 작성하는 데에는 몇 가지 규칙이 있습니다. 그러나 이것은 절대적이지 않으며, 기관이나 조직에서 따로 정의한 방식이 있다면, 그것을 따르는 것을 권장드립니다. 이건 일반적인 규칙과 팁일 뿐입니다.

• Tim Pope(= 팀 포프)가 작성한 매우 좋은 커밋 메세지 양식

(영어의 경우 대문자로) 50자 이내 짧은 요약

만약에 필요하다면 보다 자세한 설명을 여기에 쓴다. 내용은 72자 내외에서 마무리하는 것을 권장한다. 어떤 맥락에서는 첫번째 줄은 이메일의 제목처럼 취급되고 나머지가 본문으로 간주된다. 빈 칸 한 줄은 본문과 요약문 및 제목을 구분하기 위한 것으로 본문 전체를 생략하지 않은 이상 필수로 있어야 한다; rebase같은 도구들은 이 본문과 요약문 사이에 빈 칸 한 줄이 없으면 혼란스러워하는 경우도 있다.

커밋 메세지는 명령형으로 적자: 예를 들어 "Fix bug"로 적어야지 "Fixed bug"나 "Fixes bug"가 아니다. 이러한 관습은 git merge나 git revert와 같은 명령어에 의해 생성된 커밋 메세지와 일치하게 된다.

추가 문장들은 빈 칸 한 줄 뒤에 따라온다.

- 글머리 기호가 있어도 괜찮다

- 글머리는 통상적으로 하이픈(-)이나 별(*) 기호 뒤에 한 칸 띄우는 것으로 사용되고 문단과 문단 사이에는 빈 칸 한 줄을 띄우는 것으로 사용되지만 그 외 다양한 법이 존재한다

- 들여쓰기를 사용하자

이슈 트래커를 사용한다면 가장 마지막에 레퍼런스 번호를 이런 식으로 적자.

Resolves: #123

1.커밋의 종류를 명시하라 예를 들면 [FEAT], [FIX] 등등

2.제목을 본문으로부터 빈 칸 한 줄 띄워 구분하라

3.커밋 메세지는 어떠한 공백오류(whitespace errors) 를 포함하지 않아야 한다.

4.불필요한 구두점을 삭제하라

5.제목 행을 마침표(.) 로 끝맺지 마라

6.(영어일 경우) 제목 행과 매 문단의 시작을 대문자로 하라

7.제목 행에는 명령어를 사용하라

8.본문 영역은 적용한 변경 사항과 그것을 만든 이유에 대해 설명하기 위해 활용하라

9.검토자들이 본래 문제가 무엇이었는지 이해하고 있을 것이라 가정하지 말고 그것을 더해 적어라

10.본인의 코드가 설명 없이도 괜찮다고 생각하지 마라

11.소속되어 있는 팀의 정해진 커밋 규칙을 따르라

마무리

커밋 메세지는 생각보다 중요하다는 것을 절실하게 깨달았습니다. 커밋 메세지는 시간이 지나고 봐도 정확하게 커밋 메세지를 남긴 사람의 목적을 정확하게 알기만 해도 충분하다고 생각합니다. 그러기 위해서는 상세한 설명은 필수적입니다. 커밋 메세지를 쓰는 게 귀찮더라도 미래의 나에게 투자를 한다 생각하고 조금 더 고민을 하여 상세한 설명을 남기는 습관을 익히는 것이 어떨까요?