Conventional Commits 사용을 중단하라

 (sumnerevans.com)
4P by GN⁺ | ★ favorite | 댓글 2개
  • Conventional Commits는 <type>[optional scope]: <description> 형식으로 커밋 메시지에 의미를 부여하려 하지만, 변경 유형을 앞세우고 범위를 선택사항으로 둬 실제 탐색에 필요한 정보를 뒤로 미룸
  • 기여자·디버거·장애 대응자는 커밋 로그에서 변경이 닿은 코드 영역을 찾으며, 버그는 어떤 유형의 변경에서도 생길 수 있어 범위(scope) 가 유형보다 중요함
  • fix(compiler): prevent namespaced SVG <style> elements from being stripped처럼 설명만으로도 버그 수정 성격을 알 수 있고, refactor(core): Update webmcp support to use document.modelContext처럼 한 커밋이 수정·리팩터링·기능 추가에 걸칠 수 있어 type이 중복적이고 제한적임
  • 자동 CHANGELOG 생성과 시맨틱 버전 증가 판단은 커밋 로그와 변경 로그의 독자가 다르고, 되돌리기·우발적 하위 호환성 깨짐·나중의 깨짐 해소 때문에 결과가 어긋날 수 있음
  • 범위 접두사 커밋 메시지는 변경 주체를 먼저 보여 주며, 빌드·배포 조건도 제목 유형보다 git diff로 바뀐 파일을 기준으로 삼는 편이 낫음

잘못된 우선순위

  • Conventional Commits는 커밋 메시지에 의미를 부여해 개발자와 최종 사용자가 변경을 이해하도록 돕겠다는 목표를 가짐
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
  • 제목 줄은 fix, feat, chore, docs, refactor 같은 <type>, 선택적 scope, description으로 구성됨
  • 핵심 결함은 변경의 주체인 scope보다 변경 종류인 type을 우선하는 구조임
  • scope가 선택사항인 구조는 커밋에서 가장 중요한 정보가 빠질 수 있게 만들고, type을 제목 맨 앞에 둬 우선순위를 뒤집음

scope가 type보다 중요한 이유

  • 기여자는 마지막 기여 이후의 변화, 프로젝트의 전체 흐름, pull이나 rebase 때 진행 중인 작업과 충돌할 수 있는 커밋을 찾기 위해 커밋 로그를 읽음
  • 디버거는 버그가 드러난 컴포넌트와 관련된 영역을 건드린 변경을 찾으며, 버그는 어떤 type의 변경에서도 생길 수 있어 type 정보가 도움이 되지 않음
  • 장애 대응자는 장애 시점 주변의 커밋 로그를 훑어 문제를 일으킨 영역을 찾으며, 인바운드 API 오류 급증 지점에 auth scope 커밋이 있으면 유력한 원인 후보가 됨
  • 커밋 로그를 읽는 사람에게 중요한 정보는 변경이 어떤 종류였는지가 아니라 어떤 영역을 건드렸는지임

type의 중복성과 제한

자동화 약속의 한계

  • git-cliff나 conventional-changelog 같은 도구로 커밋에서 CHANGELOG를 자동 생성하는 발상은 커밋 로그와 변경 로그의 독자가 다르다는 문제를 가짐
  • CHANGELOG는 사용자 대상이며 버전 간 기능적·비즈니스적 차이를 이해하는 데 초점이 있음
  • 커밋 로그는 개발자 대상이며 코드베이스가 시간에 따라 어떻게 바뀌었는지와 scope 관점의 흐름을 읽는 데 초점이 있음
  • 중간 이상의 복잡도를 가진 프로젝트에서는 의미 있는 기능 하나가 여러 커밋으로 들어가며, 개발자에게는 구현 과정이 유용하지만 최종 사용자에게는 새 기능 자체만 중요함
  • 되돌리기(revert) 커밋은 개발자에게 커밋 로그의 흐름상 중요하지만, 최종 사용자에게는 되돌려진 변경이 만들어지지 않은 변경과 같음
  • 커밋 type에 기반한 시맨틱 버전 증가는 하위 호환성을 깨는 변경이 되돌려졌는데도 major 버전을 올리거나, 나중에야 깨짐을 알아차려 minor/patch로 잘못 올리거나, 후속 커밋과 합쳐져 깨짐이 사라졌는데도 깨짐으로 판단하는 문제를 만들 수 있음
  • 이런 상황에서 rebase로 히스토리를 고칠 수는 있지만, 워크플로가 이를 막거나 깨뜨릴 수 있고 커밋 로그가 전하는 흐름의 신뢰성을 낮춤
  • 커밋 제목 type으로 빌드·배포 프로세스를 트리거하면 docs: fix typos라는 제목의 커밋이 인증 서브시스템에 취약점을 넣는 식으로 자동 도구를 우회할 수 있음
  • 빌드·배포 조건은 커밋 제목보다 git diff로 변경 파일을 식별해 정하는 편이 낫음

적용 문제와 대안

  • Conventional Commits는 프로젝트별 type 집합을 정의하게 하지만, 많은 프로젝트가 commitlint의 기본 type을 그대로 가져가며 개별 프로젝트 특성과 잘 맞지 않을 수 있음
  • Conventional Commits 명세는 기술적으로 fix와 feat만 정의하고 추가 type은 프로젝트에 맡김
  • 기업 환경에서는 변경 관리와 감사 요구로 모든 커밋 메시지에 티켓 번호를 넣어야 하는 경우가 있으며, <scope>가 티켓 번호 자리로 쓰이면 유용한 metadata가 사라짐
  • Linux, FreeBSD, Git, Go, NixOS, Node.js는 프로젝트에 맞는 scope 접두사 커밋 메시지를 사용함
프로젝트 형식 예시
Linux subsystem: description i2c: virtio: mark device ready before registering the adapter
FreeBSD prefix: Description linuxulator: Return EINVAL for invalid inotify flags
Git area: description gitlab-ci: update macOS image
Go package: description net/http/cookiejar: add godoc links
nixpkgs pkg-name: description xwayland: 24.1.11 -> 24.1.12
Node.js subsystem: description stream: fast-path stateless transform flush results
  • Linux 커널에서는 subsystem, Go 프로젝트에서는 package path, 마이크로서비스 아키텍처에서는 microservice 이름이 자연스러운 scope가 됨
  • scopedcommits.com은 커밋 메시지에서 scope 중심 형식으로 돌아가고, CHANGELOG 생성과 커밋 로그 관리를 분리하자는 방향을 다룸
  • Conventional Commits의 장점은 실제 이점으로 이어지지 않았고, 오픈소스 프로젝트에서의 인기와 AI의 기본 선택 경향이 안티패턴이 섞인 커밋 메시지 확산을 낳음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 프로그래머들은 늘 탭과 스페이스 같은 사소한 것까지 최적의 설정이 뭔지 따지고 불평하게 되는 것 같음
    Conventional Commits가 커밋 메시지를 구성하는 신의 계시 같은 최선이라는 뜻은 아니지만, 정해진 구조가 있고 커밋 메시지에 대한 기대치를 맞추는 게 훨씬 더 효과적이고 중요하다고 봄
    작성자는 범위가 타입보다 중요하다고 크게 다루지만, fix(compiler)와 compiler fix의 차이는 굳이 목숨 걸 사안은 아니라고 생각함
    기술 업계에는 최적은 아니어도 표준이 된 것들이 많고, 예컨대 JSON도 처음부터 다시 만든다면 주석, 더 명확한 숫자 형식 등을 지원해야 한다고 많은 사람이 볼 것임
    그래도 이전 것보다 여러 맥락에서 나았기 때문에 표준이 됐고, Conventional Commits와 조금 다른 더 나은 형식이 있을 수는 있어도 커밋 메시지 구조를 두고 또 다른 경쟁 방식을 만들 만큼 낫지는 않아 보임

    • 정의된 구조가 곧 품질은 아님
      커밋 메시지는 느슨한 구조여도 변경의 성격을 잘 전달하면 훌륭할 수 있고, 반대로 매우 구조적이어도 혼란스럽거나 정보가 없을 수 있음
      대체로 작성자에게 동의하며, Conventional Commits는 나쁜 커밋 메시지라는 핵심 문제를 해결하지 못함
    • 표준화 자체는 찬성하지만, 그 논리만으로는 어떤 차선의 현상 유지도 계속 정당화할 수 있음
      XML도 충분히 좋고 표준이고, SOAP도 충분히 좋고 표준임
      Conventional Commits가 충분히 좋고 충분히 표준화돼서 다른 구조를 둘 가치가 없다는 말인데, 그 “가치”는 주관적임
      매일 커밋하고 PR을 읽는다면 Conventional Commits 형식이 만드는 작은 마찰도 누적될 수 있고, 이를 자연법칙처럼 보지 않고 다른 선택지를 두면 선호하는 팀에는 도움이 됨
      어차피 대부분의 팀은 변경 로그를 생성하지도 않음
    • 이 논쟁에 특별히 걸린 건 없지만, 원글의 반론은 공허하게 들림
      범위가 중요하다는 건 맞지만, 커밋 내용에서 유도할 수 있지 않나 싶음
      diff를 검토할 때 건드린 경로를 보는 건 중요한 sanity check이고, “test” diff가 프로덕션 인증 코드를 수정해서는 안 됨
      그래도 --oneline에서 보고 싶다면 feat(auth):가 feat:보다 낫다고 봄
      대상 독자가 틀렸다는 주장에는 동의하지 않음
      feat 커밋은 실제로 제품 관점의 변경을 설명해야 하고, 무의미한 리팩터링 변경을 먼저 잘 쌓은 뒤 작은 새 기능 변경을 위에 얹는 식으로 정리해야 함
      diff 설명에 넣기 가장 유용한 것도 이것이고, “왜 알고리즘 X를 골랐는가” 같은 기술적 맥락은 잃어버리지 않도록 주석이나 DECISIONS.md에 넣어야 함
      빠르게 움직이는 회사에서 커밋 기록에 이런 지루한 일을 챙기는 건 집착적인 사람들뿐이겠지만, 오픈소스 프로젝트에서는 커밋 메시지에 맥락을 숨겨두는 일이 훨씬 중요하다고 봄
    • 핵심은 범위가 타입보다 더 중요하다는 게 아니라, 자연어는 중요하다고 여기는 것을 강조하도록 표현할 수 있는데 모든 것을 특정 형식에 밀어 넣으면 그 정보가 사라진다는 것임
      Markdown과 일반 텍스트 같은 형식이 있고 JSON만 있는 게 아닌 데에는 이유가 있음
    • Conventional Commits가 좋은 아이디어라고 보는 이유는 도구로 사람들이 커밋 메시지에 최소한 아주 조금이라도 생각을 넣도록 강제할 수 있기 때문임
      제목이 small fix였는데 실제로는 전혀 작은 수정이 아닌 커밋을 너무 많이 리뷰해 봤음

  • 진짜 결론은 프로젝트마다 요구사항이 다르다는 것임
    30년 넘게 소스 관리를 쓰면서, 설명에 컴포넌트(글에서는 scope라고 부름)를 표준화된 방식으로 넣는 게 유용한 작업을 한 번도 해본 적 없음
    영향을 받은 파일이 소스 트리 어디에 있는지만 봐도 어떤 컴포넌트가 바뀌었는지는 명확하고, bug, fix, feature도 유용한 가치를 더하지 않음
    중요하지 않았다면 체크인되지 않았을 것임
    유용하다고 느낀 유일한 것은 글에서 전혀 다루지 않는 관련 변경 요청 링크나 ID임
    커밋에는 무엇이 바뀌었는지에 대한 정보가 이미 들어 있고, 빠진 것은 왜 바뀌었는지에 대한 맥락임
    개인 프로젝트에서도 설명 앞 대괄호 안에 JIRA 참조를 넣고, 개발 중 우연히 고치기로 한 것이라도 짧은 1줄짜리 JIRA를 만들어 ID를 받고 거기에 이유를 적음

    • “왜”는 git 커밋 메시지에 들어가야 하는 바로 그 내용임
      “왜”를 포착하는 것이 그 메시지의 전체 목적이고, 외부의 언젠가 사라질 리소스 링크 하나 붙이는 건 좋은 대체재가 아님
    • JIRA를 쓸 때는 우리도 그렇게 했음
      GitHub 이슈라면 커밋에서 PR 논의로 되돌아갈 수 있고, 그 PR에는 연결된 이슈와 다른 포인터가 있어야 함
      물론 GitHub 이슈로 옮기면서 JIRA를 거의 버렸고, 몇 년 뒤 인스턴스가 꺼지고 삭제됐음
      이제 그 JIRA 태그들은 전부 쓸모없어짐
      그래서 오히려 이슈 추적기와 git 저장소의 강한 결합이 필요하다고 봄
      정말 원하는 건 이식성인데, 강한 결합 없이는 어떻게 얻을 수 있는지 모르겠음
      이상적으로는 공개 표준 형식이 있어야겠지만, 현실에서는 GitHub가 형식을 정의하는 거대한 고릴라이고 GitLab 등 클론들이 GitHub 프로젝트 메타데이터나 최소한 PR을 가져올 수 있다면 실질적으로 그에 가까워짐
      어쨌든 5년 뒤 쓰지 않을 수도 있는 Atlassian 제품에 대한 고정 불변 포인터를 남기는 정책은 좋지 않음
      차라리 git 커밋이 완전히 독립적으로 서야 하고 변경의 “왜”에 대한 모든 정보를 커밋 메시지나 소스 주석에 녹여야 한다는 정책을 받아들이겠음
      다만 그것도 실패한다고 보는데, 사람들은 git 커밋에서 지나치게 짧게 쓰고 이슈를 요약하면서 정보를 잃어버리며, PR 논의의 왕복 대화에는 변경 이유를 한 사람 목소리로 요약한 것 이상이 들어 있어 유용하기 때문임
    • 릴리스 노트 자동 생성을 한다면 유용함
      새 기능을 먼저 묶고 그다음 버그 수정을 두면 비기술 사용자가 조금 더 읽기 쉬워짐
    • 맞음
      커밋 메시지는 변경 로그 생성을 위한 게 아니라 미래의 개발자를 위한 것임
      그 개발자가 커밋 메시지를 읽는 주된 순간은 그 커밋이 왜 존재하는지 이해하지 못할 때임
      무엇을 바꿨는지가 아니라 특정 줄의 목적이 무엇인지가 궁금한 상황임
      그래서 blame을 돌려 커밋을 보고, 원래 개발자는 이미 회사를 떠났고, 예전 JIRA도 사라졌을 수 있으며, 유일한 단서는 커밋 메시지임
      https://dev.to/splix/the-why-behind-the-code-2bb1
    • 별도 소스를 쓰는 이점이 이미지 같은 것을 넣을 수 있다는 건가, 아니면 놓친 게 있나 싶음
      커밋 본문에 맥락을 넣으면 되지 않나?

  • Conventional Commits를 쓰는 많은 사람들의 chore라는 단어는 늘 거슬렸음
    개인적으로는 여기서도 다행히 언급된 linux kernel 스타일의 커밋 제목을 선호해 왔음
    [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

    • 완전히 동의함
      chore가 암시하는 태도는 매우 거부감이 듦
      나머지는 전부 fun이나 indifferent로 표시해야 하는 것처럼 느껴지고, 그런 감정적 판단은 커밋 메시지에 들어갈 일이 아님
    • 대체 단어를 찾았음: upkeep
      같은 뜻이지만 경멸적인 뉘앙스는 없음
    • Rich의 글도 마음에 들 수 있음: https://richvdh.org/conventional-commits-considered-harmful....
    • 용어가 나쁜 건 맞음
      게다가 커밋의 전체적 영향을 미리 안다는 척하는 것이기도 한데, 실제로는 모름
      Conventional Commits가 생기면 팀원들과 LLM 모두가 그 멍청한 명명법을 만들어내느라 시간과 토큰을 써야 함

  • Conventional Commits에 대한 주된 불만은 커밋 제목에 이슈 번호가 포함되지 않는다는 점이었음
    표준 문서에서도 선택 사항으로조차 언급되지 않음
    나에게는 커밋 메시지에서 거의 가장 중요한 정보임
    지난 15년 동안 오래된 커밋이 참조한 이슈 설명을 대조해 변경의 전체 맥락을 파악한 일이 얼마나 많았는지 모름
    이 습관이 일종의 표준이라고 느꼈는데, Conventional Commits를 알고 나서야 아니란 걸 배웠음
    왜 인기 있는지 전혀 이해하지 못했음

    • 개인적으로는 이슈를 git trailer로 넣는 쪽을 선호함
      fix thing in foo

      Issue: ABC-123

      Git에는 이런 trailer를 파싱하고 포맷하는 내장 기능이 많아서, 인라인으로 보거나 CI에서 쓰도록 파싱하는 커스텀 git log 별칭을 쉽게 만들 수 있음

    • 이미 글자 수가 제한된 변경 로그를 훑고 있다면, 주 커밋 메시지에 XYZ-999999가 있는 건 별로 관심 없음
      trailer로 태그하는 건 좋지만, Jira 이슈 번호보다 커밋이 무엇을 했는지를 훨씬 더 보고 싶음

    • 이슈 키를 제목 맨 앞에 반드시 둬야 한다고 요구하는 경우에만 문제라고 봄
      그것도 가독성에는 나쁘다고 생각함
      Conventional Commits 잡다한 형식 뒤 어딘가에 그냥 붙이면 왜 안 되는지 모르겠음
      이슈 키는 영숫자 접두사 뒤 숫자 같은 정규식으로 뽑아낼 수 있어야 하므로, 이런 “표준”이 별도 공간을 마련할 필요는 거의 없음
      개인적으로는 Conventional Commits 없이, 해당 이슈와 관련된 커밋이면 끝에 괄호로 넣는 편임
      이슈를 고치는 것처럼 더 강한 관계라면 메시지에 Fixes trailer도 함께 넣음

    • 흥미롭네
      우리는 지금까지 fix(ABC-123): some message here처럼 써 왔는데, 링크도 잘 걸리고 자동 릴리스 노트에도 아주 보기 좋게 렌더링됨

    • 그건 표준이 아니라 관례임
      팀 안에서 티켓 ID를 커밋 메시지에 포함하는 표준을 정하면 됨

  • 기계가 읽을 수 있게 하고 싶다면 footer/trailer를 쓰면 됨
    Conventional Commits에 대해서는 좋게 말할 수 있는 게 없음
    형식이 메시지에서 가장 많이 읽히는 부분의 공간을 차지하고, 카테고리나 타입은 정보량이 적음
    제목에 솔직한 영어 동사를 문장처럼 넣으면 대체 가능하고, :, (), ! 같은 세 종류 문장부호보다 그냥 문장이 훨씬 잘 읽힘
    제목 안의 “영역” 정도는 참을 수 있고, 그것도 이 관례보다 먼저 있었음
    직장에서는 비기술 사용자를 위한 웹앱을 만들고, 그런 사용자용 변경 로그는 노르웨이어로 잘 쓸 수 있음
    커밋 메시지는 사용자에게 무관하고, 모든 커밋이 최종 사용자용 변경 로그에 들어갈 만큼 좋아야 한다고 요구하는 건 우리에게는 당분간 일어나지 않을 일임
    대신 footer/trailer를 쓰면 됨

  • Conventional Commits가 정말 도움이 되는 곳은 지속적 배포임
    main으로 머지될 때마다 자동으로 SemVer 태그를 붙이고 배포할 수 있는데, 태깅과 버전 관리에 필요한 판단은 개발자가 커밋 메시지를 쓸 때 이미 했기 때문임
    Linux kernel 같은 거대한 프로젝트에는 맞지 않는다는 점은 충분히 인정함
    하지만 99%의 프로젝트에서는 Conventional Commits와 SemVer를 결합하면 현재 릴리스 프로세스보다 크게 개선되고 자동화하기 쉬워짐

    • 지속적 배포 상황에서도 git tags에 의존하는 방식을 좋아함
      git describe는 지속적 배포 버전 관리에 충분할 때가 많고, v1.2.3-4-gabcdef는 커밋을 git이 만족할 만큼 정확히 설명하면서 SemVer와 비슷해 기대치를 설정할 수 있음
      새 git tags를 사람이 판단해서만 넣는 경우, 예컨대 이건 깨지는 변경이니 지금 새 메이저를 태그해야 한다는 식일 때 특히 그렇음
      git describe 형식의 버전 번호에서 실질적인 논쟁은 SemVer 기대에 더 잘 맞추기 위해 첫 번째 대시를 플러스로 바꿀지 여부 정도이고, 패키지 관리자에서 버전을 올바르게 정렬하는 등 SemVer 기대를 강제하는 쪽에 가치가 있다면 간단한 정규식으로 바꿀 수 있음
      git describe는 CD 자동화가 쉽지만, 커밋 기록의 마법 키워드로 추측하기보다 git tag 선택이나 GitHub Releases를 통해 버전 번호 결정을 사람에게 남길 수 있음
    • 내 오픈소스 프로젝트에서는 SemVer 증가를 자동화하려고 이 방식을 쓰는데 정말 좋음
      직장에서는 변화에 관심 있는 대상에 따라 “태그”도 강제함
      여기서 태그는 git 태그가 아니라 PR 제목 안의 문자열이고, 그 “태그”를 바탕으로 각 팀용 변경 로그를 생성함
    • 글에서 왜 이것이 제대로 동작하지 않는지 설명하고 있음
    • 그런데 왜 그걸 제목에 넣어야 함?
      그런 이상한 방식으로 버전을 매기고 싶다면 커밋 본문에 마법 문구를 넣으면 됨
      그러면 단어 하나로 제한되지도 않음

  • 이런 제목 스타일이 꽤 싫음
    “Stop something” 같은 표현이 매우 인기가 있어 보이는데, 명령조이고 “내가 확실히 맞다”는 느낌을 줌
    왜 “In favour of something”이나 “A case against something” 같은 식으로 쓰지 않는지 모르겠음

    • 왜 직접적으로 선호하는 입장을 명확히 옹호하면 안 되는지 모르겠음
      그 입장에 동의할 필요는 없지만, 표현을 흐리라고 요구하는 건 약한 대응임
    • considered harmful만큼 나쁘진 않지만 그래도 약간 독성이 있음
      핵심은 어떤 임의의 개인 선호, 예컨대 A와 B의 순서를 바꾸고 싶다는 정도를 실제보다 더 큰 것처럼 보이게 하려는 데 있어 보임
    • 어떤 진술이 우리의 세계관에 도전할 때 관심이 더 커짐
      많은 사람에게는 무례하지만 주의 경제는 그런 방식을 보상함
      수정: 제목을 덜 도발적으로 바꾼 것 같음
      잘한 일임
    • 비슷한 얘기를 하려고 왔음
      Conventional Commits를 별로 좋아하진 않지만, 사람들 각자 원하는 걸 쓰게 두면 됨
    • https://knowyourmeme.com/memes/stop-doing-math
      이런 장르의 제목 일부에 영향을 준 밈이 있음

  • 이상함
    이 스타일의 커밋 메시지를 쓰는 주된 이유는 CI/CD 자동화임
    수정: 처음 읽을 때 글에서 이 부분을 못 봤는데, 다뤄져 있었음
    미안함
    커밋 타입은 자동화된 워크플로가 커밋을 어떻게 처리할지 알려주기 때문에 맨 앞에 옴
    예를 들어 CD를 한다면 fix: 만 여러 개 커밋했을 때는 의미론적 버전의 패치 번호만 증가함
    feat: 를 커밋하면 마이너 버전이 올라가고, feat! 는 메이저 버전 증가임
    릴리스에 CD를 쓰지 않더라도, 의미론적 커밋 메시지는 변경 로그 생성을 자동화하는 데 쓰이기도 함
    물론 변경 로그에는 보통 Git 커밋 메시지 자체를 넣으면 안 됨
    그 메시지는 사용자가 아니라 개발자를 향한 것임

    • 글에서 이 두 가지를 꽤 명확히 다룸
      의미론적 버전 관리는 되돌리기에서 망가지고, 자동 변경 로그는 대상 독자가 잘못됨
    • 이 스타일을 버전 증가에 써 봤고 좋았기 때문에, 글에서 작동하는 대안을 제안해 줬으면 했음
      요즘은 SemVer 대신 CalVer를 써서 문제가 되지는 않았지만, 똑똑한 자동 버전 증가라는 아이디어는 마음에 듦
    • 그렇다면 git trailer에 어떤 관례를 쓰면 됨
      커밋 제목에 fix나 feat가 있어도 로그를 훑는 사람에게 유용한 정보는 제공하지 않음
    • 아니 아니
      AI가 커밋을 더 쉽게 만들 수 있도록 Conventional Commits를 없애야 한다는 거잖음

  • 순서를 뒤집으면 내 주된 짜증이 실제로 해결됨
    도대체 기능이란 무엇인가?
    refactor(core): Update webmcp support to use document.modelContext

    작성자가 말하듯 수정, 개선, 일반 정리의 경계는 흐리고, 각 의미적 변경을 별도 커밋으로 나누는 일은 어차피 나중에 squash될 수도 있어 누구에게도 이득이 없는 작업만 만들어냄
    Conventional Commits는 다른 문제를 직접 해결하기보다 SemVer 자동화를 시도하다 생긴 부산물이라고 봄
    변경 로그는 어차피 자동화하면 안 된다고 생각함
    목록이 필요하면 git log를 보면 됨
    변경 로그는 더 넓은 독자에게 내부에서 실제로 무슨 일이 일어나는지 전달할 기회임

  • “변경 로그의 독자는 커밋 로그의 독자와 완전히 다르다”
    “변경 로그는 사용자 대상이다”

    그 배는 이미 떠난 것 같음
    대부분의 회사는 “Bug Fixes & Performance Improvements”로 만족함
    적어도 노력을 들이지 않을 거라면 생성된 변경 로그가 없는 것보다는 나음

    • 매주 업데이트되는 자동 업데이트 소프트웨어에서 써본 것 중 가장 좋았던 방식은 사용자에게 보이는 커밋 앞에 uv:를 붙이는 것이었음
      그러면 매주 그것들을 검색해 텍스트를 그대로 쓰거나 살짝 다듬었음
      제품 자체의 Help/Release-notes 메뉴에도 넣었음
      내가 하지도 않고 들어본 적도 없는 일을 그만하라고 하는 건 좀 웃김
      보통은 데이터베이스 스키마 마이그레이션이나 다른 주요한 것들에만 특수 접두사를 붙임
    • 그는 변경 로그와 릴리스 노트를 혼동하고 있음
      커밋 이름도 잘 못 붙이는 것 같고, 아마 심볼 이름도 잘 못 붙일 것임
      실력 문제인데 공개적으로 슬퍼하는 중이니 넘어가면 됨
답변달기
GN⁺   [-]
Lobste.rs 의견들

  • conventional commits에 대한 반박을 본능적 거부감 말고 논리로 정리한 글이라 반갑다
    왜 싫은지 깊게 생각해보진 않았고, LLM이 생성한 코드와 연관 짓게 된 탓인가 싶었음. 특히 chore:가 제일 싫은데, 헝가리안 표기법을 다시 발명하지 말았으면 함. 애초에 만들어지지 말았어야 함

    • 특히 chore:는 더 이상 Angular 커밋 스타일 가이드에도 없고, 너무 모호하다는 걸 깨달았는지 build:에 흡수됨
      Angular 스타일에 있던 시절에도 chore: 설명은 꽤 구체적인 용도를 제시했는데, 일부 오픈소스 프로젝트에서는 말 그대로 하기 귀찮은 일처럼 느껴지는 작업에 분위기로 붙이는 듯함

  • conventional commits를 좋아하진 않지만, 제안된 대안은 scope가 선택 사항인 이유를 놓치는 것 같음
    뚜렷한 모듈이 많지 않은 작은 프로젝트에서는 “scope”라는 개념이 별로 유용하지 않음. 둘 다 빠뜨린 유용한 관행으로, 커밋 제목에 이슈나 티켓 번호를 넣으면 변경의 추가 맥락을 파악하기 쉬워지고 코드 리뷰 때 특히 도움이 됨. 다만 티켓 번호를 필수로 만들면 사소한 변경에도 쓸모없는 티켓이 양산되니 싫고, 특정 버그나 작업을 처리하는 변경이라면 해당 버그나 작업으로 연결돼야 함

    • scope가 필요 없으면 그냥 생략하면 됨
      제목 줄만 봐도 드러나야 할 중복된 커밋 “type”보다 여전히 낫다
    • 이상적으로는 어떤 규정된 커밋 스타일도 없이, 특정 커밋에 맞는 표현을 쓰면 된다고 봄
      변경이 티켓과 명확히 대응되면 “티켓 번호” 커밋을 쓰고, 그렇지 않으면 다른 방식을 쓰면 됨. 어떤 변경은 type에는 잘 맞지만 scope에는 덜 맞고, 반대도 있으니 scoped commits와 conventional commits를 섞어 쓸 수도 있음

  • “문단 텍스트에는 고정폭 글꼴을 쓰지 말라”고 말하고 싶음
    그래도 글의 전제에는 대체로 동의함

  • 커밋 메시지가 별로여도 변경 범위를 감잡으려면 git log --name-only나 git log --stat를 자주 써보는 걸 추천함
    파일명을 보면 각 커밋을 전부 열어보지 않아도 무엇이 바뀌었는지 아는 데 꽤 도움이 됨

  • 정말 마음에 드는 방식은 PR 제목에 conventional commit 스타일을 강제하는 것임
    PR 제목은 병합 후에도 maintainer가 수정할 수 있고, 커밋 기록을 다시 쓸 필요도 없으며, release-drafter 같은 도구와 함께 쓰면 GitHub 릴리스에서 의미 있는 변경 로그를 자동화할 수 있음. 작성자가 말한 이해관계자에게 맞는 적절한 입도, 즉 기능·수정·호환성 깨짐을 나눠 보여주고 다음 GitHub 릴리스 초안의 합리적인 semver도 자동으로 처리해 줌
    parse-lib 같은 컴포넌트가 선택 사항이어서는 안 된다는 글의 지적은 맞고, conventional commits를 강제하면 새 기여가 위축된다는 데도 동의함. 하지만 대안들이 딱히 더 낫진 않음
    그래도 호환성 깨짐 식별자인 fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays는 꽤 많은 정보를 줌. 특정 컴포넌트의 버그 수정이고, 그 수정에 불가피하게 따라온 호환성 깨짐이며, minor semver 증가 같은 의미를 담고 있음. 이런 건 PR 제목에 쓸 수 있음

  • 커밋 규율을 장려하는 방법으로 conventional commits에 너무 빠졌고, 결국 습관으로 굳어졌음을 인정함
    지금은 종종 제한적이고 임의적이라고 느낌. 몇몇 프로젝트에서는 그게 실제 관례인지도 모르고 Linux/Go/Node 스타일에 가까워졌는데, 다양한 설정이 있는 monorepo에서는 type을 억지로 만들기보다 [service]: [what changed]라고 쓰는 편이 자연스러웠음. 앞으로는 엄격한 관례에 맞추기보다 무엇이 유용해 보이는지 기준으로 개인 커밋 스타일을 더 실험해볼 생각이고, scoped commits는 좋은 출발점처럼 느껴짐

  • chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
    거의 전부 동의하지만, “커밋 로그가 말하는 이야기의 신뢰성을 낮추는 수정주의적 기록을 기여자에게 보여준다”는 부분은 하나 다르게 봄. 작성자는 주로 공개 브랜치를 말하는 것 같은데, 공개 브랜치라면 합리적인 조언임. 하지만 비공개 브랜치에는 적용되지 않아야 함. 최종 변경을 리뷰하는 사람, 즉 maintainer나 10년 뒤의 내가 이해하기 쉽게 만들면 되지, 앞뒤 안 맞는 사고 흐름이나 더 나쁘게는 address review 커밋 묶음을 남길 필요는 없음

  • “왜 scope가 선택 사항인가?”에 대한 답은 작은 프로젝트에는 그냥 프로젝트 전체가 scope이기 때문임
    커밋의 “type”이 그다지 유용하지 않다는 데는 동의하지만, scoped commits와 conventional commits 사이에 큰 차이가 있는지도 잘 모르겠음. scoped는 “type”이 빠진 conventional일 뿐이고, fix·feat·refactor·chore 구분은 있어도 괜찮은 구분임
    다들 commitlint 기본값을 그대로 가져다 쓴다면, 사람들이 더 잘 다루게 만들면 되는 일 아닐까 싶음

답변달기