GitRoot

 (gitroot.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • GitRoot는 단일 바이너리로 저장소와 접근 권한을 관리하고, 독립형 플러그인으로 이슈·보드·브랜치 병합·웹 인터페이스를 조합하는 소형 Git 포지임
  • 코드뿐 아니라 이슈, 병합 요청, 보드까지 모든 데이터를 일반 파일로 Git에 저장해 별도 데이터베이스나 숨겨진 blob에 의존하지 않음
  • .gitroot/users.yml과 브랜치별 쓰기 권한으로 변경을 통제하며, 저장소의 현재 상태인 기본 브랜치에는 허용된 사용자만 push할 수 있음
  • 현재 알파 버전으로 저장소·사용자·플러그인·SSH Git 명령·HTTP 조회를 지원하지만 프로덕션 용도로는 적합하지 않음
  • 1.0 전까지 업데이트, 파일 단위 권한, HTTP Git 명령, 그룹·하위 그룹, 플러그인 API 안정화를 추진하며, 현재 기여에는 Git과 grafter 플러그인 흐름에 대한 이해가 필요함

필요한 기능만 조합하는 소형 Git 포지

  • GitRoot는 바이너리 하나로 실행하는 소형 Git 포지이며, 기본 기능을 저장소 생성과 저장소별 접근 권한 관리로 제한함
  • 나머지 기능은 서로 독립적으로 설치할 수 있는 플러그인이 담당함
    • 이슈, 로드맵, 스프린트, 마일스톤 생성
    • 항목을 보드 형태로 표시
    • GitRoot에서 graft라고 부르는 브랜치 검토와 병합
    • 저장소 데이터와 여러 기능을 웹 인터페이스로 제공
  • 플러그인이 완전히 분리돼 있어 웹 인터페이스 없이 보드만 사용할 수 있고, 프로젝트에 필요한 기능을 직접 플러그인으로 만들 수도 있음

프로젝트에 맞춰 포지를 바꾸는 설계

  • 프로젝트마다 필요한 작업 방식이 다르다는 전제에서, 각 프로젝트가 자신의 포지를 수정할 자유를 갖도록 설계함
  • 개발자가 원하는 환경은 다음과 같음
    • 코드, 이슈, pull/merge request, 보드를 저장소 하나에 보관
    • 랜딩 페이지, 번역, 티켓 시스템, 포럼 등 프로젝트 홍보와 운영에 필요한 기능 제공
    • 마이그레이션 스크립트나 데이터·기여자 표시 손실 없이 다른 서버 포지로 이전
  • 반대로 다음과 같은 복잡성은 피하려 함
    • pull/merge request나 이슈를 관리하려고 브라우저를 열어야 하는 방식
    • 프로젝트를 처음 접한 사람에게 파일과 디렉터리 목록부터 보여주는 구성
    • 포지가 스프린트·마일스톤·에픽·사용자 스토리의 의미와 작업 흐름을 결정하는 방식
    • 사용자 권한 하나를 설정하려고 여러 메뉴를 거쳐야 하는 구조

설치와 운영의 자율성

  • 관리자가 쉽게 설치하고 유지하도록 의존성과 데이터베이스가 없는 배포를 지향함
  • 관리자는 사용자별 허용 작업을 설정할 수 있고, 사용자는 이메일이나 채팅 없이 프로젝트와 기능의 생성·접근을 직접 요청할 수 있어야 함
  • 업그레이드 부담을 줄이는 동시에 프로젝트와 사용자 데이터를 제3자에게 넘기지 않고, 운영 방침을 갑자기 바꿀 수 있는 대형 사업자에도 의존하지 않는 것이 목표임
  • 아직 완성되지 않은 프로젝트로 외부 기여를 받고 있음

일반 파일과 브랜치로 관리하는 권한

  • 데이터베이스나 Git 트리 내부의 숨겨진 blob 대신 코드 옆의 일반 파일에 모든 데이터를 저장함
  • 각 저장소의 .gitroot/users.yml이 사용자별 쓰기 가능 위치를 지정하며, 접근 통제는 브랜치 제한을 중심으로 작동함
    • 처음에는 소유자만 기본 브랜치에 접근할 수 있음
    • 권한이 없는 사용자가 기본 브랜치로 push하면 GitRoot가 변경을 거부함
    • 누구나 새 브랜치를 만들 수 있으며, 생성한 사용자는 그 브랜치의 쓰기 권한을 얻고 다른 사용자는 수정할 수 없음
    • .gitroot/users.yml을 수정하거나 사용자가 자신을 추가한 브랜치를 병합하면 해당 사용자도 기본 브랜치에 push할 수 있음
  • 누구나 파일을 읽고 로컬이나 새 브랜치에서 수정할 수 있지만, 저장소의 현재 상태를 나타내는 기본 브랜치로 변경을 반영하려면 소유자의 병합이 필요함
  • 포지 자체의 설정도 루트 저장소에서 관리함
    • 루트 저장소 기본 브랜치의 .gitroot/repositories.yml에 변경을 추가하거나 해당 변경을 병합하면 저장소가 생성됨
    • 자세한 작동 방식은 문서에서 확인할 수 있음

알파 버전에서 지원하는 기능

  • 현재 알파 버전이므로 시험은 가능하지만 프로덕션에는 사용하지 말아야 함
  • 지원 범위는 다음과 같음
    • 저장소 생성과 삭제
    • SSH를 통한 Git 명령 처리
    • 저장소·브랜치 수준에서 사용자별 쓰기 위치 관리
    • 플러그인 설치와 저장소별 활성화
    • 설치 시 작업 트리에서 플러그인 실행
    • 설치 후 커밋마다 diff를 대상으로 플러그인 실행
    • HTTP를 통한 저장소 조회

1.0까지의 개발 계획

  • 버전 1.0 전까지 다음 기능을 구현할 계획임
    • GitRoot와 플러그인 업데이트
    • 파일 수준 사용자 권한 관리
    • HTTP를 통한 Git 명령 처리
    • 그룹과 하위 그룹을 이용한 저장소 관리
    • 플러그인 API 안정화

자체 호스팅과 기여 절차

  • GitRoot 웹사이트는 GitRoot 코드 자체를 호스팅하는 GitRoot 인스턴스이며, GitRoot 프로젝트 전용으로 운영됨
  • 다른 프로젝트에서 시험하려면 설치 및 사용 문서를 따라야 함
  • GitRoot 자체도 GitRoot 저장소이므로 같은 방식으로 기여할 수 있으며, 절차는 기여 안내에서 확인할 수 있음
  • 현재 인스턴스는 코드 일부를 기본 브랜치에 통합하는 grafter 플러그인을 사용하므로, 기여 전에 그 작동 방식을 이해해야 함
  • 코드, 이슈, 번역을 포함한 모든 데이터가 Git에 저장되기 때문에 현재 기여하려면 Git 사용법을 알아야 함
  • 향후에는 브라우저에서 git commit과 git push를 직접 실행해 누구나 참여할 수 있도록 만드는 것을 목표로 함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들
  • GitHub은 가장 큰 Git 포지일 뿐 아니라 가장 영향력 있는 포지였고, Forgejo와 GitLab의 설계에서도 그 흔적이 느껴짐. GitHub의 쇠퇴를 계기로 기존 모델에서 벗어난 다양한 포지가 등장할 수 있어 혁신의 여지가 커 보임
    • Gitea는 과거 GitHub 프런트엔드를 거의 1:1로 복제했고, Forgejo가 Gitea에서 포크하면서 그 형태를 그대로 물려받았음
  • GitRoot를 만든 사람이며, 궁금한 점이 있다면 편하게 질문해도 됨
    • 세 가지가 궁금함. CSS를 축소된 상태로 커밋한 이유는 무엇인지 궁금함: https://gitroot.dev/worktree/app/…
      <pre> 태그 너비가 720px로 제한되는 원인은 body의 display:grid로 보이며, 이를 해제하면 예상대로 넓어짐. 또한 URL에 특정 커밋 시점 정보가 없어 링크를 보낸 사람과 받은 사람이 같은 화면을 보기 어려움. 개인적인 필요를 위한 프로젝트라는 점은 이해하며, 검토할 만한 사항으로 전달하고 싶었음
  • @manland, LLM으로 만든 기여물을 허용하거나 금지하는 정책 또는 지침이 있는지 궁금함
    • 현재는 별도 정책이 없음. 일회성 기여자 두 명을 제외하면 코드의 99.999%를 직접 작성했기 때문임
      개인적으로 코딩에 LLM을 사용하지 않고 반대하지만, LLM을 썼더라도 패치가 충분히 작다면 거절할지는 확신하기 어려움
      영어가 모국어가 아니어서 GitRoot를 설명하기 어려운 탓에 대외 소통에는 LLM의 흔적이 있음. 예전에도 https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 와 https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 에서 도움을 요청했지만 아무도 오지 않았음
      LLM을 써야 한다는 사실이 마음 아프지만, 아무것도 하지 않는 대신 최소한으로 사용하기로 했음. 향후 커뮤니티가 생기면 완전히 배제하고 싶으며, 그전에 경제적 이유로 자연스럽게 사라질 수도 있다고 봄. 철학·보안·미래를 설명할 글이 할 일 목록에 많지만, 결국 LLM이 문장을 고치거나 오타를 수정하고 번역할 것이라는 생각 때문에 집필을 망설이게 됨
  • Go 플러그인을 WASM으로 컴파일하는 데 TinyGo를 활용한 점이 마음에 듦
답변달기