GitRoot

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에 변경을 추가하거나 해당 변경을 병합하면 저장소가 생성됨
- 자세한 작동 방식은 문서에서 확인할 수 있음