▲

Git Notes: Git의 가장 멋지고 미움받는 기능 (2022)

 (tylercipriani.com)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Git notes는 커밋 등에 메타데이터를 덧붙일 수 있는 강력한 도구임
  • 이 기능은 커밋 메시지를 수정할 수 없을 때 보충 정보를 저장할 수 있도록 해줌
  • 코드 리뷰 이력이나 테스트 결과 등 다양한 정보를 저장하는 데 활용 가능함
  • 분산 코드 리뷰 시스템까지 구현할 수 있으나, 사용성과 인지도가 낮음
  • GitHub에서 비활성화되는 등 지원이 부족해 일상적 채택이 저조함

Git notes란 무엇인가

  • Git notes는 git에서 추적되는 어떤 오브젝트(커밋, 블롭, 트리)에도 메타데이터를 덧붙일 수 있도록 하는 기능임
  • 일반적으로 한 번 기록된 커밋 메시지는 변경할 수 없으나, git notes를 사용하면 커밋 본문을 변경하지 않고도 새로운 정보를 추가할 수 있음
  • 예를 들어 아래와 같이 커밋에 notes를 추가 가능함
    • git notes add -m 'Acked-by: <이메일>'
  • notes는 git log에서 별도의 섹션으로 함께 표시됨

실제 활용 사례

  • git 자체 프로젝트에서도 git notes를 활용하여 커밋과 메일링리스트 내 토론 스레드를 연결하고 있음
  • notes의 실제 활용 예시로는 다음과 같은 항목이 있음
    • 커밋 또는 브랜치별 작업 시간 추적
    • 코드 리뷰 및 테스트 결과 로그 저장
    • 완전히 분산된 코드 리뷰 시스템 설계

코드 리뷰와 테스트 결과 저장

  • 코드 포지나 리뷰 시스템들이 코드 리뷰 메타데이터를 오프라인, 즉 git 자체에 저장하도록 지원하는 사례가 늘어나고 있음
  • Gerrit의 reviewnotes 플러그인은 git log에서 리뷰 수행자와 테스트 실행 내역을 notes로 함께 보여줌
    • 사용자는 브라우저를 별도로 열지 않고도 로컬에서 코드 검토 내역을 확인 가능함

분산 코드 리뷰 시스템

  • Google에서 개발된 git-appraise처럼, git notes를 이용해 분산 코드 리뷰를 실현한 사례가 존재함
  • git-appraise는 코드 리뷰 요청, 변경 사항에 대한 코멘트, 리뷰 후 머지 등 모든 절차를 git notes에 기록하고, 온라인 코드 호스팅 서비스와 무관하게 독립적으로 동작함
  • 로컬 환경에서 모든 협업이 가능하며, 웹 인터페이스까지 제공함

낮은 사용성과 인지도

  • Git notes는 인터페이스가 불편하고 일반 사용자에겐 직관적이지 않아 거의 사용되지 않고 있음
  • GitHub는 2014년 이후 커밋 notes 노출을 중단함에 따라 더욱 사용 기회가 줄어듦
  • 커밋에 대한 notes 관리만큼은 git 설정으로 좀 더 쉽게 할 수 있으나, 블롭이나 트리 오브젝트에 notes를 붙이려면 git의 내부 구조(plumbing)에 대한 추가적인 이해가 필요함
  • 그 결과로 git notes는 여전히 매니아적이고 인지도가 매우 낮은 기능으로 남아 있음

오픈 포지(Forge) 독립성

  • git 자체는 분산 버전 관리와 코드 리뷰를 지원할 수 있으나, 리뷰 내역 등 많은 부가 가치는 GitHub와 같은 호스팅 서비스에 종속되는 경향이 강함
  • Git notes 기능을 활용하면 코드 자체의 변천사뿐 아니라 프로젝트 전체의 히스토리까지 분산 방식으로 저장 및 배포하는 길이 열림
  • 이는 온전한 분산 개발 생태계와 기록 보존에 중요한 의미가 있음
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • Git 트레일러라는 덜 알려진 기능이 존재 정보 공유, 트레일러는 커밋 생성 시 key-value 형태의 메타데이터 삽입 가능, Gerrit에서 Change-Id를 부착하는 데 활용. 관련 기사 링크

    • PostgreSQL에 COMMENT라는 비슷한 기능이 있음 정보 공유, COMMENT는 데이터베이스 객체에 텍스트를 추가할 수 있음, PostgreSQL이 key-value 형태의 구조화된 메타데이터 편집 기능도 제공하길 희망. 관련 문서 링크

    • 오픈소스 업스트림 작업 시, 단위 테스트가 완료된 커밋을 표시하려고 git notes 사용 경험 공유, git rebase -i로 브랜치를 다듬을 때 유용했음, 하지만 트레일러가 현재는 더 나은 방법처럼 보임, Change-Id 같은 기능이 git 자체에 포함되면 툴들이 이를 더 잘 이해할 수 있을 것 같음, 커밋 메시지로 커밋을 구분하는 것은 미묘하게 취약함, 커밋 id는 유일성은 좋지만 동일한 변경을 다른 커밋 위로 옮기면 식별자로서 유용성이 떨어짐, 수정(수정 내용): 트레일러는 커밋의 일부라 notes를 완전히 대체하진 못할 것

    • 최근 GitHub이 [skip ci] 대신 별도 트레일러 활용을 알게 됨, 아마 커밋 메시지에서 쉽게 분리해내기 위해서인 듯함, GitHub에서 왜 마지막 트레일러만 요구하는지 확실하지 않음, 아마 정규표현식 처리 때문일 것 추측. 관련 문서 링크

    • 트레일러 기능은 처음 알게 됨, Conventional Commits 팬으로서, 트레일러가 이런 메타데이터 추가에 더 나을 것 같음, 커밋 메시지에 수동 추가와 --trailer 플래그 사용하는 것이 기능적으로 동일한지 궁금

    • 자연스럽게 이슈 트래킹 시스템과 연동하고 싶지만, 트레일러 같은 곳에 그걸 넣기는 이슈 트래커에서 너무 멀리 떨어져 있어서 비효율, 이슈 트래커는 트렌드에 따라가고 여러 기능이 늦게 추가되는 문제, 티켓명에서 파생된 브랜치명을 PR 제목으로 무조건 써야 하는 규칙이 불편, 다른 메타데이터로 커밋과 이슈를 연결해서 PR 제목을 더 의미있게 만들고 싶음, 쉽게 바꿀 수 있는 문제가 아니라서 인터넷에서나 하소연하는 주제

  • Forgejo가 올해 1월 출시된 10버전부터 트레일러 지원 시작 정보 공유 릴리즈 노트 풀 리퀘스트

  • git notes와 히스토리 재작성(amend, rebase 등) 기능의 상호작용에 대한 궁금증, notes가 커밋/트리/블랍 ID에 연결되어 있어서 새로운 커밋으로 교체될 때 notes가 복사되는지, 혹은 사라지는지 궁금, interactive rebase로 여러 커밋을 합칠 때는 어떻게 되는지 궁금, notes가 파일/디렉터리의 "내용"에 붙는다는 점에서 기대와 다르다는 인식 공유, 예를 들어 "Hello world!" 문자열 blob에 note를 붙이면 같은 내용을 가진 모든 파일에 note가 붙는 것인지, 파일이 변경되면 notes를 잃는지 궁금

    • git rebase 등에서 notes 복사는 기본적으로 복사되도록 설정 가능, git-config(1)에서 notes.rewrite 옵션 참고

  • 현재 직장에서 git notes 적극적으로 사용 중, 내부 코드 리뷰 기록을 커밋 메시지를 복잡하게 하거나 모든 변경에 PR을 만들지 않고도 관리 목표, 각 커밋에 어떤 티켓과 매핑되고 인프라 제약, 수정의 경우 인시던트 스레드 링크 등 브랜치에 컨텍스트를 남김, 이 정보를 repo에 저장해서 slack이나 jira 검색 없이도 한 줄이 왜 바뀌었는지 파악 쉽게 가능, 대규모로 활용하면 platform UI의 필요성을 확실히 줄일 수 있음, reproducibility가 빌드 뿐만 아니라 ‘intent’에도 필요하다는 의견

    • 이런 정보가 커밋 메시지에 들어가는 편이 낫지 않은지, 아니면 “이 커밋이 버그 #123을 만들었다” 같은 미래 방향까지 링크하려는 목적이 있는지 궁금

  • git notes는 커밋 이후에 추가 정보가 필요할 때만 진짜 유용, Acked-By, 메일링리스트 토론 링크 같은 예시는 커밋 당시 이미 알고 있는 정보이므로 커밋 메시지에 추가하면 됨, 오히려 git note의 진짜 장점은 나중에 되돌린 커밋 등에 부가적 설명을 붙일 때라고 생각

    • 흔히 commit 메시지가 버그를 고쳤다 자랑하지만 사실은 안 고쳤을 때가 있음, 그로인해 꼬리에 꼬리를 무는 버그들이 발생하고, 동료들이 최초 작성 의도를 무시하고 대충 넘어가는 경우가 많았음, 화난 고객과 버그 재발 경험 후에는 bug fix에 신중해질 필요성 느낌, 때로는 여러 버그를 한 번에 고치거나, 리팩터로 성능 개선이나 새로운 기능의 기회도 열림

    • Acked-By, 리뷰, 토론은 커밋 후에 이어질 수밖에 없음, 이미 커밋되는 시점엔 알지 못함, 되돌린(commit revert) 사례는 오히려 커밋 메시지에 추가하는 게 쓸모 있음, blame 기능이 가장 최근 변경을 보여주기 때문에 revert된 커밋도 자연히 추적 기능 제공

    • 커밋 이후에도 토론이 계속되는 경우 많음

  • 코드 에이전트에 추가 컨텍스트 제공 목적으로 notes 기능을 탐구해볼 만한 흥미로운 포인트라고 생각

  • 이건 지식 부족이 아닌 UI 문제, GitHub UI가 notes를 잘 보여주면 바로 더 많이 쓰이게 될 것

    • GitHub에서 notes 지원되길 바람

  • git에는 bisect, pickaxe, reflog, range-diff, archive, annotated tags 등 ‘가장 멋지고 사랑받지 못하는 기능’이 많은데, 대부분 사람들이 google drive처럼만 여겨서 잘 안 씀

    • git notes는 어차피 별도의 프로젝트 관리 도구(예: Jira)로 feature, roadmap 등 비기술적 맥락 추적하므로 중복 느낌, 유닉스 철학에 따라 각자 역할에 집중해야 함

    • pickaxe는 처음 들어본 기능이라 예상 밖, 너무 자신만만해지면 안될 것 같음

    • 이런 장식적인 기능들이 실제로는 그렇게 유용하지 않은 경우가 많음, 본질을 둘러싼 잡기술이라는 시각

  • git notes는 정말 ‘멋진’ unloved feature가 아니라 특정한 아주 제한적 상황에서만 쓸모 있었다는 의견, 진짜 필요한 정보는 커밋 메시지에 모두 담아서 다른 시스템(예: JIRA)에서 참조하는 패턴이 오히려 장점, JIRA 같은 시스템은 개발자가 아닌 비즈니스 애널리스트/서포트 담당자와 소통 창구 역할, 개발자가 아닌 사람들이 repo와 코드 접근 권한 없는 것도 합리적, 여러 서비스/레포를 동시에 다루는 상황에선 notes 따위로는 feature 참조가 현실적으로 불가능, 외부 시스템과 연동돼야 함

    • 비즈니스 애널리스트가 코드나 리포에 접근하지 못한다는 것이 비효율임을 지적, 실제로 코드 한 줄만 보면 알 수 있는 걸 매번 질문받는 상황, 기술적인 역량을 갖춘 애널리스트도 있지만 문화가 쉽게 바뀌지 않는다는 현실적 한계 언급

  • man 페이지를 통해 notes를 2020년경에 처음 알게 됨, 기본적으로 notes는 로컬 repo에만 적용되어 실제 활용 경험은 없음, pushing/fetching을 별도로 설정해서 팀 단위로 사용 결정해야 하는데, 내 팀은 그걸 채택하지 않음

답변달기