# Gitolite

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31659](https://news.hada.io/topic?id=31659)
- GeekNews Markdown: [https://news.hada.io/topic/31659.md](https://news.hada.io/topic/31659.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-21T22:01:09+09:00
- Updated: 2026-07-21T22:01:09+09:00
- Original source: [gitolite.com](https://gitolite.com/gitolite/index.html)
- Points: 1
- Comments: 1

## Topic Body

- **Gitolite**는 중앙 서버에서 Git 저장소를 호스팅하며, 저장소별로 **세밀한 접근 제어**를 적용할 수 있게 함
- 패키지 관리자로 설치할 때는 흔히 **`gitolite3`** 라는 이름을 사용하며, 소스 코드는 Codeberg와 GitHub에서 제공됨
- Unix와 SSH에 익숙하면 **빠른 설치 문서**를, 단계별 안내가 필요하면 전체 문서 흐름이나 오류 방지 설치 가이드를 따르면 됨
- 설치·설정 오류와 키 분실은 emergencies 문서에서 다루며, **보안 문제는 이메일로 직접 신고**하고 일반 지원은 메일링 리스트를 이용함
- 소프트웨어는 **GPL v2**로 배포되며, 별도로 관리되는 문서에는 원칙적으로 Creative Commons BY-NC-SA 3.0이 적용됨

---

### 설치와 운영 문서
- [Gitolite](https://codeberg.org/sitaramc/gitolite)는 중앙 서버에 Git 저장소를 구성하고 **세밀한 접근 제어**를 적용할 수 있게 함
  - 대체 소스 저장소로 [GitHub](https://github.com/sitaramc/gitolite)도 이용할 수 있음
  - 패키지 관리자의 패키지명은 흔히 **`gitolite3`** 임
- Unix와 SSH에 익숙하다면 [빠른 설치](https://gitolite.com/gitolite/quick_install.html)를 참고할 수 있음
- 단계별 지원이 필요하면 [오류 방지 설치 가이드](https://gitolite.com/gitolite/fool_proof_setup.html)를 그대로 따르고, 설치 후 일반 작업에는 [cookbook](https://gitolite.com/gitolite/cookbook.html)의 예제를 활용할 수 있음
- [emergencies](https://gitolite.com/gitolite/emergencies.html)는 설치·설정 문제와 **분실한 키 복구**, 일반적이거나 드문 오류, 문제가 될 수 있는 비표준 구성을 다룸

### 지원 채널과 라이선스
- **보안 문제**는 `sitaramc@gmail.com`으로 직접 신고함
- 일반 지원과 토론은 Google Groups 메일링 리스트를 이용함
  - 새 회원의 첫 이메일은 승인될 때까지 보류되지만, 같은 주소에서 보낸 후속 이메일은 보류되지 않음
  - 릴리스와 보안 공지를 위한 별도의 저빈도 단방향 메일링 리스트도 제공됨
- IRC 지원은 libera.chat의 **`#gitolite`** 채널에서 받을 수 있으며, Git 채널 `#git`에도 Gitolite에 익숙한 사용자가 있음
- Gitolite 소프트웨어는 **GPL v2**로 배포됨
  - 문서에는 원칙적으로 [Creative Commons BY-NC-SA 3.0](https://creativecommons.org/licenses/by-nc-sa/3.0/)이 적용되지만, 외부 기여 부분은 각 파일에 별도 라이선스가 표시될 수 있음
  - 문서의 코드 예제와 관련 주석은 공정 이용에 해당하지 않는다고 판단할 경우 GPL v2로 간주할 수 있음
- GIT은 Software Freedom Conservancy의 상표이며, **Gitolite** 명칭은 라이선스에 따라 사용됨

## Comments



### Comment 62175

- Author: neo
- Created: 2026-07-21T22:01:11+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/21lrrw/gitolite) 
- 2013년 Cambridge University에서 gitolite와 gitweb 기반 Git 서버를 구축했음. 초기 GitLab이나 Gitorious보다 관리 시간이 훨씬 적게 들 것 같아 선택했고, 실제로도 대체로 그랬음  
  gitolite는 SSH로 명령을 실행하고 정교한 설정 파일로 접근 권한을 관리하는 독특한 구조라 웹 관리 콘솔이 없어 진입 장벽이 있었음. [입문 안내](https://web.archive.org/web/20170205185602/https://git.csx.cam.ac.uk/tutorial.html)를 만들었지만 [기술에 자신 있는 사용자](https://web.archive.org/web/20170205123454/https://git.csx.cam.ac.uk/admin.html)에게만 적합했음  
  Git 서비스에 배정된 인력은 전혀 없었기에 수요를 입증하고 예산을 확보하고자 개인 시간을 들여 임시 서비스를 만들었음. 오픈소스의 로컬 변경 사항을 SVN에 보관하거나, 아무도 찾을 수 없는 홈 디렉터리에 Git 저장소를 두는 것은 받아들이기 어려웠음. 대학의 과학 프로그래밍 수요에 비해 소프트웨어 공학 지원이 부족했고, 중앙 IT 서비스는 내부 용도에 그치지 않고 대학 전체의 교육과 연구를 지원해야 한다고 봤음  
  **사용자 관리 위임** 기능을 활용해 각 연구 그룹이나 학과의 전문가에게 계정 관리와 지원을 거의 모두 맡겼음. 난해한 도구인 덕분에 의도했던 전문적인 얼리어답터가 모였고, 사용자는 상당히 많았지만 지원 요청은 거의 없었음. 여러 대학이 참여하는 프로젝트도 Cambridge 구성원으로 접근을 제한하지 않아 지원할 수 있었음  
  가장 큰 오판은 임시 서비스가 **약 8년**이나 지속되리라 예상하지 못한 것이며, 이후 전담 인력이 운영하는 GitLab로 교체됨. 가장 많은 시간이 든 작업은 복원력 개선이었고, 다른 사이트로 Git 저장소를 준실시간 복제하는 구조는 필요 이상으로 복잡했을 가능성이 큼
  - 이 서비스를 이어받을 당시에는 지속적 통합과 패키지 저장소 등을 제공하는 **소프트웨어 포지**로 이전하려 했음. 연구 성과물로서 소프트웨어의 가치가 인정되기 시작하면서 대학 중앙 서비스에 예산을 투입하려는 분위기도 있었음  
    마침 Microsoft가 GitHub를 인수해 GitHub의 쇠퇴가 처음 예측되던 시기였는데, 역사가 반복되는 모습이 흥미로움. GitLab이 매우 유리한 조건으로 라이선스를 제공했고, 클라우드 서비스에 Kubernetes와 코드형 인프라를 적용하는 내부 시연도 필요했음. 지금은 대학을 떠났지만 GitLab은 여전히 https://gitlab.developers.cam.ac.uk/ 에서 운영 중임
  - 2012~2013년 지역 대학의 한 학과에서 gitolite를 운영했으며, 주로 **소프트웨어 공학 전공 학생**들이 사용했음. 사용자 규모에 비하면 과했지만 단순성과 세밀한 접근 제어 목록 덕분에 학과 내 여러 프로젝트의 팀과 권한을 관리하기 좋았음  
    몇 년 뒤 운영을 맡을 사람이 없어졌고 GitHub가 크게 유행하면서 사용자가 대학 내부 서비스 대신 외부 호스팅으로 이동함. 프로젝트가 사라진 줄 알았는데 지금도 꾸준히 유지되는 모습이 반가움

- gitolite의 **세밀한 접근 제어 목록**을 이용해 어떤 키에는 복제만 허용하고 푸시는 막거나, 푸시는 허용하되 강제 푸시는 금지할 수 있었음. 가볍고 편리했으며, 지금이라면 https://github.com/djmdjm/gitlimit 를 사용해볼 것 같음
  - Gitlimit은 소스 코드가 단순해 **사용자 정의 명령** 같은 기능도 쉽게 확장할 수 있어 보임

- 개인 프로젝트라면 **Fossil**도 적합함. 작은 바이너리에 웹 서버가 내장돼 간단히 서비스할 수 있고, 필요하면 상위 Git 저장소와도 연동 가능함
  - gitolite는 복잡한 접근 제어가 필요한 다수 사용자와 **여러 저장소 호스팅**을 위한 도구임

- NRAO에서도 gitolite를 임시방편으로 한동안 사용했음. 당시 공식 지원 도구는 Subversion이었지만, 그룹 책임자가 Git을 원하는 내부 사용자들을 위해 설치해 줬음. 기능은 많지 않았으나 필요한 일은 충분히 잘 처리했음  
  현재는 천문대 전체가 사용하는 **GitLab 설치본**이 있으며 GitHub나 GitLab로 옮길 가능성도 있지만 최종 결정은 모름. 지속적 통합·배포 시스템을 손보는 데 많은 시간을 쓰는데, gitolite로 이를 지원하거나 풀·병합 요청 작업 흐름을 구현할 방법은 떠오르지 않음. 다만 그런 기능의 효용이 과장됐을 수도 있음

- 극도의 단순함을 목표로 만든 **fugit**(https://github.com/cbdevnet/fugit)을 사용하고, Nix 모듈로 설정 파일을 관리함. 간단하고 효과적이며 gitolite는 늘 사용하기 조금 번거로웠음