좋은 commit과 commit 메시지는 어떤 것인가요?

Question

Accepted Answer

좋은 commit은 **집중되어** 있고(하나의 논리적 변경) 무엇이 변경되었고 왜 변경되었는지 설명하는 **명확한 메시지**를 가집니다. 잘 만들어진 commit과 메시지는 프로젝트 히스토리를 읽기 쉽게 만들어 변경 사항 이해, 디버깅, 협업에 유용합니다.

## 좋은 commit 메시지

```text
좋은 메시지 구조:
  짧은 요약 줄(~50자, 명령형, 첫 글자 대문자, 마침표 없음)
  <빈 줄>
  선택적 본문: 무엇(WHAT)과 왜(WHY)를 설명(어떻게는 아님 — 코드가 어떻게를 보여줌),
  ~72자에서 줄바꿈. 관련 있으면 이슈 참조.
```

```text
✅ 좋음:
  Add user email validation to registration form

Validate email format before submission to prevent invalid
  accounts. Fixes #142.

❌ 나쁨:
  "fixed stuff", "update", "asdf", "changes", "wip"
  → 모호하고 정보가 없음 — 나중에 히스토리를 검토할 때 쓸모없음
```

## 명령형 관례

```text
요약을 명령/지시(명령형)로 작성:
  ✓ "Add feature", "Fix bug", "Update docs", "Remove dead code"
  ✗ "Added feature", "Fixes bug", "Updating docs"
→ 관례: "이 commit은 [기능을 추가]할 것이다"로 읽힘(Git 자체 메시지와 일치).
```

## 좋은 commit: atomic하고 집중됨

```text
✓ ATOMIC — 각 commit은 하나의 논리적 변경(여러 무관한 변경을 한 덩어리로 묶지 않음)
✓ 집중됨 — "Add login"과 "Fix typo"는 하나가 아닌 별개의 commit
✓ 작동함 — 이상적으로 각 commit은 코드를 작동 상태로 남김
이유: 집중된 commit은 리뷰, revert(하나의 변경을 깔끔하게 되돌림),
  이해, bisect(어느 commit이 버그를 도입했는지 찾기)가 더 쉬움.
```

## Conventional Commits(인기 있는 표준)

```text
type(scope): description    → feat: add login | fix: handle null | docs: update README
  타입: feat, fix, docs, refactor, test, chore 등
→ 자동 changelog/버전 관리 가능; 많은 프로젝트에서 널리 채택됨.
```

## 왜 중요한가

좋은 commit과 commit 메시지가 무엇인지 이해하는 것은 **읽기 쉽고 유용한 프로젝트 히스토리를 만드는 데** 가치 있으므로, 협업과 유지보수성에 큰 영향을 미치는 중요한 실무 지식입니다. **좋은 commit 메시지**가 중요한 이유는 commit 히스토리가 중요한 문서의 한 형태이기 때문입니다. 명확한 메시지(*무엇*이 변경되었는지 설명하는 간결한 요약과 필요할 때 *왜*를 설명하는 본문)는 코드가 어떻게, 왜 발전했는지 이해할 수 있게 하며, 이는 히스토리를 검토하거나 디버깅(변경 이유 파악)하거나 온보딩할 때 매우 유용합니다.

모호한 메시지("fixed stuff", "update", "wip")는 히스토리를 쓸모없게 만들어 나중에 변경 사항을 이해할 수 없게 합니다. 이는 실제 비용입니다.

**명령형 관례**("Added feature"가 아닌 "Add feature")는 알아둘 가치가 있는 널리 따르는 표준입니다. **좋은 commit이 atomic하고 집중되어 있는 것**(각 commit이 하나의 논리적 변경이고 여러 무관한 변경을 한 덩어리로 묶지 않음)도 똑같이 중요합니다. 집중된 commit은 **리뷰**(리뷰어가 하나의 변경을 이해), **revert**(다른 것에 영향을 주지 않고 하나의 변경을 깔끔하게 되돌림), 이해, **bisect**(어느 commit이 버그를 도입했는지 찾기)가 훨씬 쉽습니다. 따라서 commit 구조는 디버깅과 협업을 위해 히스토리가 얼마나 유용한지에 직접 영향을 미칩니다.

**Conventional Commits**(자동 changelog와 버전 관리를 가능하게 하는 `type(scope): description` 표준)를 아는 것은 널리 채택되어 있어 가치가 있습니다.

commit 히스토리는 중요한 문서이고 좋은 commit/메시지는 이를 읽기 쉽고 유용하게(이해, 리뷰, 디버깅, 협업을 위해) 만드는 반면 나쁜 것은 쓸모없게 만들며, 명확한 메시지를 가진 집중된 commit을 만드는 것이 전문적인 Git 관행의 특징이므로, 좋은 commit과 commit 메시지가 무엇인지 이해하는 것은 효과적인 협업과 유지보수 가능한 히스토리를 위한 가치 있고 실무적으로 관련된 지식입니다. 이는 사려 깊은 개발자를 구별 짓고 프로젝트의 장기적 유용성과 팀 워크플로를 의미 있게 개선하는 기술입니다.