# GitRoot

> Clean Markdown view of GeekNews topic #31568. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31568](https://news.hada.io/topic?id=31568)
- GeekNews Markdown: [https://news.hada.io/topic/31568.md](https://news.hada.io/topic/31568.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-19T09:01:36+09:00
- Updated: 2026-07-19T09:01:36+09:00
- Original source: [gitroot.dev](https://gitroot.dev/)
- Points: 2
- Comments: 1

## Topic Body

- **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`이 사용자별 쓰기 가능 위치를 지정하며, 접근 통제는 **브랜치 제한**을 중심으로 작동함
  - 처음에는 소유자만 [기본 브랜치](https://gitroot.dev/docs/technicals/default_branch.html)에 접근할 수 있음
  - 권한이 없는 사용자가 기본 브랜치로 push하면 GitRoot가 변경을 거부함
  - 누구나 새 브랜치를 만들 수 있으며, 생성한 사용자는 그 브랜치의 쓰기 권한을 얻고 다른 사용자는 수정할 수 없음
  - `.gitroot/users.yml`을 수정하거나 사용자가 자신을 추가한 브랜치를 병합하면 해당 사용자도 기본 브랜치에 push할 수 있음
- 누구나 파일을 읽고 로컬이나 새 브랜치에서 수정할 수 있지만, 저장소의 현재 상태를 나타내는 기본 브랜치로 변경을 반영하려면 **소유자의 병합**이 필요함
- 포지 자체의 설정도 루트 저장소에서 관리함
  - 루트 저장소 기본 브랜치의 `.gitroot/repositories.yml`에 변경을 추가하거나 해당 변경을 병합하면 저장소가 생성됨
  - 자세한 작동 방식은 [문서](https://gitroot.dev/docs)에서 확인할 수 있음

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

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

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

## Comments



### Comment 62017

- Author: neo
- Created: 2026-07-19T09:01:38+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/z01edy/gitroot) 
- **GitHub**은 가장 큰 Git 포지일 뿐 아니라 가장 영향력 있는 포지였고, Forgejo와 GitLab의 설계에서도 그 흔적이 느껴짐. GitHub의 쇠퇴를 계기로 기존 모델에서 벗어난 다양한 포지가 등장할 수 있어 **혁신의 여지**가 커 보임
  - Gitea는 과거 GitHub 프런트엔드를 거의 1:1로 복제했고, Forgejo가 Gitea에서 포크하면서 그 형태를 그대로 물려받았음
- GitRoot를 만든 사람이며, 궁금한 점이 있다면 편하게 질문해도 됨
  - 세 가지가 궁금함. **CSS를 축소된 상태로 커밋한 이유**는 무엇인지 궁금함: https://gitroot.dev/worktree/app/server/resources/styles/simple.min.css.html  
    `<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**를 활용한 점이 마음에 듦
  - TinyGo는 훌륭하며 AssemblyScript와 Rust용 SDK도 있음. 현재 **Zig용 SDK**를 개발 중임: https://gts.gitroot.dev/@forge/statuses/01KXRJ1GE0CNEQHVQ0R41D7V06