[GIT] 커밋에 관하여(좋은 커밋 메시지, 커밋 타이밍 등)

---

프로젝트의 버전을 관리할 때 커밋 메세지 작성은 필수다.

하지만 어떤 메세지를 언제 커밋해야 나에게 더 나아가 팀원들에게 도움이 될 수 있을지 알고 싶었다.

좋은 변수 컨벤션이 있는 것 처럼, 효율적인 커밋 메세지 작성을 위한 개발자들의 노력이 있었다.

가장 유명한 컨벤션은 Udacity의 컨벤션인 것 같아 이를 참고해 정리해보겠다.

---

커밋 메시지 구조

 

type: Subject

body

footer

 

타입은 필수 요소, 바디와 푸터는 옵션이다.

제목은 메세지의 타입과 주제를 포함한다.

 

타입

 

타입은 아래 리스트 중 하나만을 포함한다.

 

• feat: 새로운 기능

• fix: 버그 해결

• docs: 문서 변경

• style: formatting, 놓친 세미콜론 등... 코드의 변경은 없음

• refactor: 코드 리팩토링

• test: 테스트 코드 추가 혹은 테스트 코드 리팩토링. 코드의 변경은 없음

• chore: 패키지 매니저 구성, 빌드 작업 업데이트. 코드의 변경은 없음

 

주제

 

주제는 50자를 넘어서는 안된다. 대문자로 시작해야 하며 마침표로 끝나면 안된다.

커밋이 수행 한 작업에 대해 명령형으로 작성한다. 

 

바디

 

모든 커밋들이 바디를 적어야 할 정도로 복잡하진 않기 때문에 바디는 옵션이고, 커밋이 약간의 설명과 문단이 필요할 때 바디가 사용된다. 

'어떻게'가 아닌 '무엇을' 그리고 '왜'에 대한 설명을 위해 바디를 사용해야한다.

 

바디를 적을 때, 타이틀과 바디 사이에 공백을 적어야 하고 각 줄에 글자가 72자를 넘지 않도록 해야한다.

 

푸터

 

푸터도 옵션이고, 이슈트래커 아이디 참조로 사용된다.

 

---

커밋 메세지 예시

 

fix: CardList 컴포넌트 클릭 시 공백으로 나오는 오류 수정


모바일 버전에서 CardList의 img 부분 클릭 시 공백으로 나오는 오류 수정.
PC버전은 이상없음.


Resolves: #232

---

커밋을 해야할 때

 

커밋은 그래서 언제 해야할까? 자주 해야 좋은걸까?

30분에 한 번씩? 의미가 있을 때?

커밋의 횟수에 대해서는 정해진 컨벤션은 없었다.

대신 커밋을 얼마나 자주 해야하는 질문들에 up-vote를 많이 받은 답변들을 모아봤다.

 

 

• 어떤 기능에 대한 테스트가 끝났을 때. 보통 한 시간에 두 번 정도. 다섯번은 너무 많다.

• 기능에 기반해서 커밋을 해야지 시간을 정해서 커밋을 하면 안된다. 새로운 기능을 추가했을 때 기능이 커밋할 만 하거나, 작동하는 메소드를 추가했거나, 글씨를 수정했거나, 잘못된 파일 들여쓰기를 수정했거나 등등일때 커밋해야한다. 커밋이 의미가 있다면 작은 것을 커밋하는 것은 전혀 잘못된점이 아니다. 의미 없는 너무 잦은 커밋은 히스토리로 이슈를 추적하는데 있어서 읽기 어렵게 한다.

• 새로운 테스트 케이스를 추가할 때, 테스트가 통과됐을 때, 변수 이름을 변경했을 때, 메소드를 삭제했을 때, 상태를 변경했을 때 등... 사실 커밋한 대상의 중요성은 중요하지 않다

---

 

많은 경우를 살펴본 것은 아니지만, 포토샵 파일 저장하듯 특정 시간마다 저장하는 것이 아닌, 

의미있는 코드의 변화가 있을 때, 사소하고 말고를 따지지 않고 커밋하는 듯 하다.

히스토리로 살펴봤을 때 이슈 트래킹에 불편하지 않을 정도로 커밋을 해야 함도 알았다.

 

정답이 없다는 말은 개개인의 경험에 따라 맞는 커밋 방법이 있다는 생각도 든다.

 

---

 

참고:

When to commit work in git?

깃 커밋 메시지 컨벤션

How often should I/do you make commits? [duplicate]