썸남 썸녀한테 문자 보내듯이 성실히 쓰자

목적

나는 개발을 배우기 시작한 지 거의 반년이 되어가는 현재까지도 커밋 메시지를 작성하는 목적인 코드 변경 사항을 명확하고 일관되게 기록을 잘 하지 못하고 있다. 최근에는 그나마 이를 자각하고, 나중에 다시 보더라도 알아볼 수 있도록 작성하고는 있지만, 여전히 많이 부족하다고 느껴서 이 글을 쓰게 되었다.

오타 고치고 뭘 써야 할지 몰라서 헤매고 있는 1인... (개발 1~2달 차)

커밋 메시지를 작성하는 이유

1. 변경 사항 추적
   어떤 코드를 변경했는지, 왜 변경했는지 쉽게 알 수 있다. 특히 팀 프로젝트에서 다른 개발자들이 코드 변경 사항을 이해하는 데 도움이 된다.

2. 문제 해결
   버그가 발생했을 때, 이전 커밋 메시지를 보고 문제가 발생한 시점과 원인을 추적할 수 있다.

3. 히스토리
   프로젝트가 진행되면서 어떤 기능이 추가되었는지, 어떤 개선이 이루어졌는지 등 개발 히스토리를 기록하는 역할을 한다.

작성 규칙

작성 규칙에는 총 7가지가 있는데, 사실 규칙이라고 하기에는 조금 애매하다. 아래에 써진 것은 딱히 정해진 형식이 없을 때를 위해 있는 것이고, 팀원과 합의된 형식이 있다면 그게 진짜 규칙이다.

1. 제목(한 줄)은 변경 사항을 간단히 요약하고, 필요 시 본문(여러 줄)에서 더 자세한 설명을 추가한다.

2. 제목은 50자 이내로 작성한다.

3. 제목은 동사로 시작한다. (예시: Add, Fix, Update, Remove 등등)

4. 본문은 변경 이유, 수정한 버그, 추가된 기능 등을 설명합니다. 72자 이내로 줄바꿈을 권장합니다.

5. 일관된 어조를 유지하고, 필요한 경우 이슈 번호를 포함합니다. (예시: "Fixes #123")

6. 구체적이고 이해하기 쉽게 작성합니다. (예시: "fix: login bug")

7. 팀 내에서 합의된 형식을 따릅니다.

기본 형식

타입: 제목  <- header (타입은 필수 X)

본문       <- body (필수 X)

바닥글     <- Footer (필수 X)

예시

fix: login bug

- Google 로그인 오류 수정
- 사용자가 정상적으로 로그인할 수 있도록 개선

fixes #45

타입

타입	설명
feat	새로운 기능 추가
fix	버그 수정
docs	문서 관련 변경
style	코드 포맷팅, 세미콜론 누락 등
refactor	코드 리팩토링
perf	성능 개선
test	테스트 추가 또는 수정
chore	빌드 과정이나 보조 도구 변경

마무리

오늘은 커밋 메시지를 작성하는 이유, 규칙, 구조, 그리고 타입에 대해 공부했다. 솔직히 혼자 프로젝트를 할 때는 본인만 이해할 수 있게 써도 상관없겠지만, 협업을 할 때는 작성 규칙과 형식을 잘 지키면, 팀원과의 소통이 원활해지고, 소통이 원활해진만큼 더 좋은 결과물이 나올 수 있을 것 같다.