컨텐츠로 건너뛰기
레시피 생태계 소스 코드 문서

일관된 커밋 메시지 작성하기

깔끔한 커밋 히스토리는 코드 리뷰, bisect, changelog 생성을 훨씬 쉽게 만듭니다. OpenCode는 스테이지된 diff를 읽고 팀의 컨벤션을 따르는 메시지를 생성합니다.

이 레시피를 사용하는 경우

  • 기능을 완성했고 관련 없는 변경이 한꺼번에 스테이지되어 있는 경우
  • 팀에 손으로 따르기 번거로운 커밋 메시지 컨벤션이 있는 경우
  • 나중에 bisect하거나 revert할 수 있는 깔끔한 히스토리가 필요한 경우

사전 준비

  • 저장소에 설치된 OpenCode
  • .gitmessage 템플릿 또는 팀 컨벤션 (Conventional Commits, 커스텀 접두사 등)
  • 작업 트리에 준비된 변경 사항

단계

  1. 스테이지된 내용 검토

    스테이지 영역이 커밋하려는 의도와 일치하는지 확인하세요.

    git status
git diff --cached --stat

  2. 메시지 제안을 요청

    diff를 OpenCode에 전달하고 Conventional Commit 메시지를 요청하세요.

    스테이지된 diff를 읽고 Conventional Commit 메시지를 제안하세요. type(scope): subject 형식을 사용하세요. subject는 명령형으로, 72자 미만이어야 합니다. 본문은 무엇이 아닌 왜를 설명해야 합니다.

  3. 필요 시 스테이지를 해제하고 재그룹화

    diff에 여러 관련 없는 변경이 섞여 있다면, OpenCode에게 논리적 커밋으로 분리해 달라고 요청하세요.

    이 diff에는 버그 수정과 리팩터링이 섞여 있습니다. 두 커밋으로 어떻게 분리할지 제안하세요. 각 커밋에 어떤 파일이 들어가야 하는지, 각 커밋의 메시지를 작성해 주세요.

  4. 각 그룹을 커밋

    각 그룹을 별도로 스테이지하고 커밋하세요. OpenCode가 제안한 메시지를 사용합니다.

    git reset HEAD
git add <files-for-first-commit>
git commit -m "fix(parser): handle empty input without panic

Previously an empty input caused a nil deref in the lexer.
Added an early return and a unit test."

  5. 히스토리가 잘 읽히는지 검증

    마지막 몇 개 커밋을 보고 일관된 이야기를 전달하는지 확인하세요.

    git log --oneline -10

핵심 프롬프트

스테이지된 diff를 읽고 Conventional Commit 메시지를 제안하세요. 그런 다음 diff를 보고 별도의 커밋으로 분리해야 할 관련 없는 변경이 여러 개 포함되어 있는지 알려주세요. 포함되어 있다면 각 커밋에 어떤 파일이 들어가는지 나열하고 각각의 메시지를 작성하세요.

검증

  • git log --oneline이 깔끔한 내러티브로 읽힘
  • 각 커밋이 독립적으로 빌드되고 테스트를 통과
  • 메시지가 팀 컨벤션(예: type(scope): subject)을 따름

흔한 실수

  • 관심사 혼합: “오타 수정 + 새 기능 + 포맷 변경” 커밋은 안전하게 revert할 수 없습니다. 항상 먼저 재그룹화하세요.
  • 모호한 subject: “fix stuff” 또는 “update code”는 미래의 본인에게 아무것도 알려주지 않습니다. 항상 구체적인 subject를 요구하세요.
  • 본문 컨텍스트 누락: 왜는 diff만 봐서는 거의 명확하지 않습니다. OpenCode가 1-2줄 본문을 작성하도록 하세요.

관련 문서

  • 정책 — 프로젝트 전반에서 OpenCode가 변경을 적용하는 방식을 제어
  • 설정 — OpenCode 동작을 제어하는 opencode.json 파일

관련 레시피

관련 문서

다음 단계