▲

`git who` – 이 코드 누가 작성했어?!

 (github.com/sinclairtarget)
8P by GN⁺ 13일전 | ★ favorite | 댓글 1개
  • git-who는 코드베이스의 전체 구성 요소나 하위 시스템에 대한 책임자를 찾는 CLI 도구
  • git blame과 달리, git-who는 파일 트리 단위로 작동하여 코드 작성자를 식별함
  • 세 가지 서브 커맨드를 제공하며, 각각의 하위 명령어는 Git 저장소의 저작권에 대한 다른 관점을 제공

    • table

      • 기본값으로, 저장소에서 커밋한 모든 작성자의 기여를 요약한 표를 출력함
      • 경로를 지정하여 특정 경로의 파일에 대한 커밋만 필터링할 수 있음.
      • 브랜치 이름, 태그 이름, 또는 "commit-ish"를 지정하여 특정 커밋에서 도달 가능한 커밋만 필터링할 수 있음
      • -m, -c, -l, -f 플래그를 사용하여 다양한 메트릭으로 테이블을 정렬할 수 있음

    • tree

      • 파일 트리를 출력하며, 각 노드는 해당 경로에서 가장 많이 기여한 작성자를 표시함
      • -a 플래그를 사용하여 모든 파일을 주석 처리할 수 있음
      • -l, -f, -m, -c 플래그를 지원함

    • hist

      • 커밋 활동의 히스토그램/타임라인을 출력하여 저장소에 대한 기여 역사를 보여줌
      • -l 및 -f 플래그를 지원함.
  • 커밋 필터링을 위한 추가 옵션
    • --author 및 --nauthor 옵션을 사용하여 포함하거나 제외할 작성자를 지정할 수 있음
    • --since 및 --until 옵션을 사용하여 특정 날짜 이전 또는 이후의 커밋을 필터링할 수 있음
  • 캐싱 : XDG_CACHE_HOME에 저장소별로 데이터를 캐시함. 캐싱을 비활성화하려면 GIT_WHO_DISABLE_CACHE=1을 설정
  • git-who 바이너리를 경로에 설치하면 추가 설정 없이 git who를 실행할 수 있음. 다른 이름으로 설치하거나 명시적으로 설정하려면 Git 설정에 Alias를 추가할 수 있음
  • .mailmap 파일이 Git 저장소에 존재하면 git who는 이를 존중하여 동일한 사람의 커밋을 함께 계산

  • 메트릭

    • 커밋 수: 경로를 수정한 커밋 수를 나타냄
    • 파일 수: 작성자가 수정한 고유 파일 수를 나타냄
    • 추가된 줄 수 및 제거된 줄 수: 경로에 추가되거나 제거된 줄 수를 나타냄

  • git blame과의 차이점

    • git blame은 작업 트리의 코드를 기준으로 각 줄을 도입한 커밋을 식별하는 반면,
    • git who는 커밋 로그의 일부를 탐색하여 기여를 집계함
    • 두 도구는 서로 다른 수준에서 작동하며, 서로 다른 정보를 제공함
▲
GN⁺ 13일전  [-]
Hacker News 의견

  • "vim을 누가 작성했는가" 분석과 관련하여, 워크플로우에 따라 내부 기여자가 더 많이 기여한 것으로 보일 수 있음

    • 패치나 풀 리퀘스트가 내부 기여자에 의해 병합 전에 재포맷되면, 동일한 작업이 두 번 계산되거나 재포맷한 사람에게만 기여가 귀속될 수 있음
    • 결과가 틀린 것은 아니지만, 기여 과정에 대한 검토 없이 결과에서 의미를 도출할 때는 주의가 필요함

  • 이 도구는 정말 멋짐. 하루를 마무리하기 전에 잠시 사용해봤음

    • 개인적인 위시리스트는 다음과 같음
      • 블레임 기반 통계. Bob과 Alice의 기여를 보는 것도 좋지만, 모듈/파일의 실질적인 소유자를 보여주는 것이 더 유용할 것임
      • 패턴 기반 포함/제외 지원. 예를 들어, 테스트에 사용되는 json 파일이나 자동 생성된 파일의 통계는 보고 싶지 않음
      • 설정 파일 지원. git 저장소에 선호 설정을 저장할 수 있는 TOML 기반의 파일이 있으면 좋겠음
      • 더 나은 패키징. 예를 들어, v0.6의 리눅스 tarball에는 애플 관련 "쓰레기"가 포함되어 있고, gnu tar가 아카이브 형식 불일치를 경고함

  • git 블레임은 많은 사람들이 오해하고 있음. 누가 했는지가 아니라, 어떤 커밋이 원인인지에 대한 것임

  • git-who를 git who로 호출할 수 있음. 글로벌 Git 설정에서 별칭을 설정하면 됨

    • 별칭 없이도 작동함. 기본적으로 git whatever는 경로에서 git-whatever를 찾아 실행함

  • 저사양 버전으로 "nerdwars"라는 별칭을 사용하여 "git shortlog -ns --no-merges"를 실행함. 이는 프로젝트의 주요 기여자를 파악하는 좋은 방법임

  • Gitlab/Github는 제출된 병합 요청이 수정된 코드 라인의 마지막 작성자에게 자동으로 이메일을 보내는 기능을 추가해야 함

  • 이 도구는 훌륭함. 앱의 각 릴리스에서 AI와 인간이 작성한 코드 양을 추적하기 위해 git-blame 회계를 사용함

    • "블레임 스크립트"가 저장소 크기가 커지면서 느려지고 있음. 캐싱을 추가하려고 했음
    • 파일 패턴에 기반하여 통계를 제한하는 기능을 추가할 생각이 있는지 궁금함

  • tig는 멋진 TUI git 프론트엔드이며, 아름다운 tig blame 서브 커맨드를 가지고 있음

  • git에서 놓치고 있는 것은 개발자가 작성한 라인 수나 커밋 수가 아님. 오히려 다음과 같은 것임

    • 누가 이 라인을 삭제했는가
    • 누가 이 메서드의 소유자인가

  • 어떤 사람들은 두 개의 다른 이메일을 사용하여 커밋함. 예를 들어, 집 컴퓨터와 회사 컴퓨터에서 각각 다른 이메일을 사용함. 이를 동일한 것으로 정의할 수 있으면 좋겠음

답변달기