Git-bug: Git 저장소에 내장하는 분산형 오프라인 우선 버그 추적기

AI 요약

Git-bug는 별도 서버나 프로젝트 파일 없이 Git 저장소 안에 버그 추적 데이터를 저장합니다. 인터넷 연결이 끊긴 환경에서도 이슈를 작성하고 편집한 뒤, 일반 Git 원격 저장소에 git bug push와 git bug pull 명령을 실행해 동료와 데이터를 주고받습니다. 이슈 목록은 git bug ls로 확인하며 상태나 수정 시점을 기준으로 필터링·정렬하고, 텍스트 검색도 할 수 있습니다.

사용 방식

기본 작업은 CLI에서 합니다. git bug user create로 사용자 정체성을 만들고 git bug add로 이슈를 작성합니다. show, comment, open, close 같은 명령으로 이슈를 조회하거나 수정합니다. 대화형 터미널 UI를 실행하는 git bug termui도 제공합니다.

웹 UI에서는 이슈를 검색하고 필터링하며 새 이슈를 열거나 제목·라벨·상태를 편집할 수 있습니다. 저장소 파일 탐색, 구문 강조, 커밋 기록과 diff 확인도 지원합니다. 웹 UI는 Go 실행 파일에 포함되고 로컬 HTTP 서버로 제공되며, 백엔드와 GraphQL API로 통신합니다. 다만 외부 사용자가 인증을 거쳐 이슈를 등록하는 공개 포털 기능은 아직 개발 단계입니다.

기존 추적기와 연동

GitHub, GitLab, Jira, Launchpad에서 이슈를 가져오거나 변경 사항을 내보내는 브리지를 지원합니다. git bug bridge pull과 git bug bridge push로 동기화하며, 브리지마다 지원하는 기능은 다를 수 있습니다. 프로젝트는 디스크 저장 형식도 명세합니다. 여기에는 DAG 기반 엔터티 형식, 사용자 정체성, 이슈 엔터티가 포함됩니다.

개발 방향

작성자는 가까운 계획으로 웹 UI의 외부 인증과 Git 원격 엔드포인트 지원, 저장소 사이에서 정체성을 공유하기 쉬운 구조로의 개편을 제시합니다. 이후 pull request와 CI 지원을 더해 로컬 우선 방식의 자체 호스팅 코드 협업 도구로 확장하는 구상도 밝혔습니다.

Hacker News 반응

• @bonjune — GitHub 이슈 추적기가 Git 자체에 들어간 것 같네요. 흥미롭습니다!
  • @Lucasoato — GitHub에서 하는 일 중 얼마나 많은 기능이 실제로 Git 자체에 들어가 있는지 누가 알겠어요.
• @lolakutty — Fossil SCM에서 배운 사람이 있네요. 정말 좋아 보입니다.
• @bflesch — 정말 괜찮아 보입니다. 왜 이 이름과 기능을 가진 프로젝트가 진작 없었는지 궁금하네요. ‘git bug’라는 이름은 버그와 기능의 구분을 생각하면 범위가 좁아 보입니다. 기능을 추적할 때 ‘git bug’를 쓰면 어색할 수도 있겠네요. 버그만 잘 추적하고 기능 로드맵은 다른 시스템이나 절차에서 관리한다면 괜찮을 수도 있겠습니다.
  • @dizhn — 로고가 무당벌레니까 결국 다 잘 맞습니다.
  • @Towaway69 — 요즘은 모든 게 버그 아닌가요? 고쳐지고 나서야 기능이 되잖아요. ;)
  • @sodapopcan — 고쳐지지 않으면 가끔 기능이 되기도 합니다.
  • @Meneth — Bugzilla는 거의 30년 동안 기능을 추적할 때도 ‘bug’라는 말을 써 왔습니다. 별로 방해가 되지 않는 것 같네요.
  • @michaelmure — pull request 같은 기능까지 확장하고 싶어서 CLI 명령어 이름에 자리를 마련해야 합니다. git bug bug와 git bug pr이 나란히 있으면 꽤 못생겼겠네요. 이름 짓기는 어렵지만, 여기까지 확장할 줄은 몰랐습니다 :-)
• @Aissen — b4 유지관리자이자 LF IT 디렉터인 Konstantin Ryabitsev가 이번 주 Kernel Recipes 행사에서 b4와 cgit(kernel.org 포크)의 git-bug 지원을 시연했습니다. (링크)
  • @mcepl — 와! 이 내용이 cgit upstream에도 전달됐나요?
• @Izkata — 몇 달 전 Epiq라는 비슷한 프로젝트가 올라왔습니다. 10여 년 전에도 이런 분산형 추적기가 인기를 얻었던 시기가 있었고, 당시 사용하기 어려웠던 이유를 정리한 댓글과 링크를 남겼습니다. 지금은 이 프로젝트를 살펴볼 시간이 없지만, 그 문제가 해당되는지 누군가 확인하면 유용할 것 같습니다.
  • @lelanthran — 목록의 첫 번째 항목을 빼면 제 프로젝트가 나머지 문제를 다룹니다. 링크는 지금 찾기 어렵지만 GitHub에서 ‘rotsit’(revenge of the something issue Tracker)라는 이름으로 볼 수 있습니다. [1] 이슈를 브랜치에 묶는 게 핵심입니다. 현재 확인 중인 브랜치에서 이슈가 해결됐다고 표시되면 해당 브랜치에서는 해결된 상태입니다. 이슈를 브랜치와 분리해 저장하면 어느 브랜치에서 문제가 발생했는지 메타데이터를 추가로 저장해야 합니다.
• @teddyh — 이런 개념이 처음인 분들을 위해 덧붙이면, 분산형 버그 추적기는 꽤 많이 있습니다. (링크)
  • @mcepl — 그런데 제대로 작동하는 건 하나도 없습니다. 이 블로그 글은 10년이 넘었지만 상황은 별로 나아지지 않았습니다. (링크)
• @michaelmure — 안녕하세요, 작성자입니다. 관심을 보여 주셔서 반갑습니다 :-) 가까운 계획은 웹 UI가 GitHub OAuth 같은 외부 인증을 받아 공개 포털에서 외부 사용자의 참여를 지원하게 하는 것, 웹 UI에 Git 원격 엔드포인트를 제공하는 것, 저장소 사이에서 정체성을 더 자연스럽게 공유하도록 정체성 체계를 약간 바꾸는 것입니다. 공개 키 배포를 위해 Bluesky의 정체성 시스템인 did:plc를 기반으로 삼을 가능성이 있지만, ATProto를 도입하려는 건 아닙니다. 이후 pull request와 CI도 지원해 간편하게 자체 호스팅하는 로컬 우선 코드 협업 도구로 만들고 싶습니다. 관심이 모이는 만큼 이 프로젝트를 전업으로 할지도 고민 중입니다. 지속적으로 개발할 방법이나 기회에 조언이 있다면 알려 주세요!
  • @delf — Git-bug가 정말 좋아 보입니다! GitSocial 작성자인데, 의견을 듣고 싶습니다. (링크)
  • @sebiw — 우선 뭔가를 완성해 공개하신 점을 크게 존중합니다. 정말 유용해 보입니다. 전업으로 개발하는 방법을 찾는다면 특별 기능과 지원을 제공하는 엔터프라이즈 요금제를 생각해 볼 수 있습니다. 다만 그런 제품을 살 고객층은 소프트웨어에 돈을 쓰기까지 시간이 걸릴 수 있어 수익화가 매우 어려울 거라는 게 제 경험입니다. 개발자에게 팔기는 어렵고, 상사에게 팔아야 한다는 말도 있죠. 기부나 창작자 중심 모델은 가능할지도 모르겠습니다.
• @imagent — 순수 Git만으로 코드 리뷰도 할 수 있습니다. google/git-appraise를 참고하세요. 저는 git-bug를 써 봤는데 Markdown 편집기에서 티켓을 수정할 수 없는 점이 아쉬웠습니다. 그래서 ticketry를 만들었습니다. (링크)

원문: GitHub / 번역·요약: Trawling