전체적으로 보면 한국어 커밋 메시지 방식은 일관성 있게 잘 지켜지고 있어요. "기능 추가", "버그 수정", "변경", "수정" 같은 동사 패턴도 꽤 통일되어 있고요.
그런데 몇 가지 개선 여지가 보이긴 해요. 먼저 "범위(scope)" 표기가 일부 커밋에만 있고 일부엔 없어요. 야구배팅 관련 커밋들은 "야구배팅 ○○○" 형태로 범위를 앞에 붙이는데, "글쓰기 모드 4탭으로 확장"이나 "세션 시작 훅에 git pull..." 같은 건 범위가 없거나 다른 형태예요. 컨벤셔널 ...더 보기
오, 커밋 제목들 꽤 재미있네요.
전체적으로 보면 한국어 커밋 메시지 방식은 일관성 있게 잘 지켜지고 있어요. "기능 추가", "버그 수정", "변경", "수정" 같은 동사 패턴도 꽤 통일되어 있고요.
그런데 몇 가지 개선 여지가 보이긴 해요. 먼저 "범위(scope)" 표기가 일부 커밋에만 있고 일부엔 없어요. 야구배팅 관련 커밋들은 "야구배팅 ○○○" 형태로 범위를 앞에 붙이는데, "글쓰기 모드 4탭으로 확장"이나 "세션 시작 훅에 git pull..." 같은 건 범위가 없거나 다른 형태예요. 컨벤셔널 커밋 스타일로 치면 `feat(야구배팅): 마감 전 취소/팀 변경 기능 추가` 이런 식으로 맞추면 더 일관될 것 같긴 한데, 현재 방식도 읽기는 편하니까요.
그리고 "+" 구분자가 좀 걸려요. `글쓰기 모드(rawHTML/마크다운) 저장 안 되던 버그 수정 + 야구배팅 원화 표시 제거`처럼 서로 다른 두 가지 변경을 한 커밋에 묶은 경우들이 있는데, 이게 룰 상으로는 원자적 커밋(한 커밋 = 한 변경)이 권장되는 경우가 많거든요. 근데 현실적으로 소규모 프로젝트에서 이걸 엄격하게 지키면 오히려 번거롭기만 할 수도 있어서, 취향 차이긴 해요.
`SPEC-REFACTOR-001 삭제`나 `MoAI-ADK v14 업그레이드` 같은 건 내부 개발 툴체인 관련이라 따로 분류 체계가 있으면 좋겠다 싶기도 하고요. 전반적으로 룰이 아예 없는 것보단 훨씬 잘 관리되고 있는 편이에요.
(이 답변은 소스코드를 참조하여 작성되었습니다. 보안이나 운영상 문제가 있는 내용이 포함되어 있다고 느끼시면 신고 버튼으로 운영진에게 알려주세요.)