Crontab 파이썬 스크립트 실행 안될 때 환경변수 PATH 문제 해결 완벽 정리

날짜:
0

좋은 커밋 메시지 작성법: Semantic Commit Message 가이드 feat fix chore 완벽 정리

날짜:

커밋 메시지를 대충 "수정", "버그 픽스" 정도로 작성하고 있다면, 3개월 후 코드 히스토리를 추적할 때 반드시 후회하게 됩니다. 협업 환경에서 커밋은 단순한 기록이 아니라 팀원과의 커뮤니케이션 수단이며, 장애 발생 시 빠른 롤백을 위한 생존 도구입니다. 이 글에서는 Semantic Commit Message 규칙을 중심으로, 실무에서 바로 적용 가능한 커밋 작성법을 정리합니다.


좋은커밋메시지작성법SemanticCommitMessage가이드featfixchore완벽정리




1. 커밋 메시지의 3단 구조: 제목/본문/꼬리말

효과적인 커밋 메시지는 제목(title), 본문(body), 꼬리말(footer) 세 파트로 구성되며, 각 파트는 빈 줄로 구분합니다.

  • 제목(Title): 50자 이내로 변경 내용을 명령문 형태로 작성 (예: "Add login button")
  • 본문(Body): 변경한 이유(Why)와 구체적인 내용(What)을 설명. 코드만 보고 알 수 없는 맥락을 기록
  • 꼬리말(Footer): 이슈 트래커 번호(Resolves: #123) 또는 API 파괴적 변경 경고(BREAKING CHANGE:) 명시

실무 팁: 제목만으로 부족할 때만 본문을 작성하십시오. 간단한 오타 수정이나 설정 변경은 제목만으로 충분합니다. Git CLI에서 git commit 실행 시 vi 에디터가 열리면, i로 입력 모드 진입 → 작성 후 ESC → :wq로 저장합니다.

2. Semantic Commit 주요 타입(Type) 분류

커밋 메시지 앞에 붙이는 타입은 변경의 성격을 한눈에 파악하게 해줍니다. 아래는 실무에서 가장 많이 사용하는 타입입니다.

  • feat: 새로운 기능 추가 (예: feat(auth): Implement JWT refresh token logic)
  • fix: 버그 수정 (예: fix(payment): Resolve null pointer exception on refund API)
  • chore: 빌드 설정, 패키지 매니저 설정 등 코드 변경 없는 잡무 (예: chore: Update Dockerfile base image to node:18)
  • refactor: 기능 변경 없이 코드 구조 개선 (예: refactor(user): Extract validation logic to separate module)
  • docs: 문서(README, API 명세) 수정
  • style: 코드 포맷팅, 세미콜론 누락 등 동작에 영향 없는 변경
  • test: 테스트 코드 추가/수정
  • perf: 성능 개선 (예: perf(db): Add index on user_id column)
  • ci: CI/CD 파이프라인 설정 변경

주의사항: style과 refactor를 혼동하지 마십시오. style은 Prettier 같은 포맷터가 수정한 내용이고, refactor는 로직 구조를 개선한 것입니다.

3. 스코프(Scope)와 이모지 활용법

타입 뒤에 괄호로 스코프(Scope)를 추가하면 변경 범위를 명확히 할 수 있습니다. 나중에 특정 모듈의 히스토리만 필터링할 때 유용합니다.

  • feat(navigation): Add breadcrumb component
  • fix(checkout): Prevent duplicate order submission
  • chore(docker): Update PostgreSQL version to 14.5

팀에서 합의했다면 이모지를 타입 앞에 추가해 시각적 구분을 강화할 수 있습니다.

  • 🎉 Initial Commit (프로젝트 시작)
  • ✨ feat: Add OAuth2 login (새 기능)
  • 🐛 fix: Resolve memory leak in cache module (버그 수정)
  • 🚀 chore: Deploy v2.1.0 to production (배포)
  • 🐳 chore(docker): Update docker-compose.yml (Docker 관련)
  • ⚡️ perf!: Change user query to use Redis cache (파괴적 변경 + 성능 개선)

실무 팁: 이모지는 GitHub/GitLab에서는 잘 보이지만, Jira 연동 시 깨질 수 있습니다. 팀 도구 스택을 확인한 후 도입하십시오.

4. BREAKING CHANGE와 이슈 참조 규칙

API 스펙 변경이나 하위 호환성이 깨지는 수정은 반드시 꼬리말에 명시해야 합니다.

  • feat(api)!: Change response format of /users endpoint
    BREAKING CHANGE: Response now returns { data: [], meta: {} } instead of flat array

이슈 트래커와 연동할 때는 꼬리말에 이슈 번호를 추가합니다.

  • Resolves: #234 (이슈 해결)
  • Ref: #456 (참조만)
  • Closes: #789 (이슈 종료)

주의사항: ! 기호는 타입 뒤에 붙여 파괴적 변경을 표시하는 Conventional Commits 2.0 규칙입니다. 꼬리말의 BREAKING CHANGE:와 함께 사용하면 자동화 도구(semantic-release 등)가 메이저 버전을 올립니다.

5. 커밋 메시지 작성 체크리스트

커밋하기 전에 아래 항목을 확인하십시오.

  1. 제목은 50자 이내인가?
  2. 제목은 명령문 형태인가? ("Added" ❌ → "Add" ✅)
  3. 타입(feat/fix/chore)이 정확한가?
  4. 스코프를 추가해 검색 가능성을 높였는가?
  5. 본문에 "왜(Why)" 변경했는지 기록했는가?
  6. 파괴적 변경이 있다면 BREAKING CHANGE:를 명시했는가?
  7. 관련 이슈 번호를 꼬리말에 추가했는가?

결론 및 Action Item

좋은 커밋 메시지는 미래의 나와 팀원을 위한 투자입니다. 제목에 타입과 스코프를 명시하고, 본문에 변경 이유를 기록하며, 파괴적 변경은 꼬리말에 경고하는 3단 구조를 습관화하십시오. 지금 당장 실행할 수 있는 액션 아이템은 다음 커밋부터 "feat(scope): 제목" 형식을 적용하는 것입니다. git log --oneline으로 히스토리를 확인했을 때, 3개월 전 커밋도 한눈에 이해할 수 있다면 성공입니다.


#함께 읽으면 좋은 글

GitHub Actions CI/CD 입문 가이드: 커밋 시 자동 배포 구현하기 : 바로보기

댓글

댓글 쓰기