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을 별도로 설정해서 팀 단위로 사용 결정해야 하는데, 내 팀은 그걸 채택하지 않음
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 notes 적극적으로 사용 중, 내부 코드 리뷰 기록을 커밋 메시지를 복잡하게 하거나 모든 변경에 PR을 만들지 않고도 관리 목표, 각 커밋에 어떤 티켓과 매핑되고 인프라 제약, 수정의 경우 인시던트 스레드 링크 등 브랜치에 컨텍스트를 남김, 이 정보를 repo에 저장해서 slack이나 jira 검색 없이도 한 줄이 왜 바뀌었는지 파악 쉽게 가능, 대규모로 활용하면 platform UI의 필요성을 확실히 줄일 수 있음, reproducibility가 빌드 뿐만 아니라 ‘intent’에도 필요하다는 의견
git notes는 커밋 이후에 추가 정보가 필요할 때만 진짜 유용, Acked-By, 메일링리스트 토론 링크 같은 예시는 커밋 당시 이미 알고 있는 정보이므로 커밋 메시지에 추가하면 됨, 오히려 git note의 진짜 장점은 나중에 되돌린 커밋 등에 부가적 설명을 붙일 때라고 생각
흔히 commit 메시지가 버그를 고쳤다 자랑하지만 사실은 안 고쳤을 때가 있음, 그로인해 꼬리에 꼬리를 무는 버그들이 발생하고, 동료들이 최초 작성 의도를 무시하고 대충 넘어가는 경우가 많았음, 화난 고객과 버그 재발 경험 후에는 bug fix에 신중해질 필요성 느낌, 때로는 여러 버그를 한 번에 고치거나, 리팩터로 성능 개선이나 새로운 기능의 기회도 열림
Acked-By, 리뷰, 토론은 커밋 후에 이어질 수밖에 없음, 이미 커밋되는 시점엔 알지 못함, 되돌린(commit revert) 사례는 오히려 커밋 메시지에 추가하는 게 쓸모 있음, blame 기능이 가장 최근 변경을 보여주기 때문에 revert된 커밋도 자연히 추적 기능 제공
커밋 이후에도 토론이 계속되는 경우 많음
코드 에이전트에 추가 컨텍스트 제공 목적으로 notes 기능을 탐구해볼 만한 흥미로운 포인트라고 생각
이건 지식 부족이 아닌 UI 문제, GitHub UI가 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을 별도로 설정해서 팀 단위로 사용 결정해야 하는데, 내 팀은 그걸 채택하지 않음