Gitolite: Fine-Grained Git Repository Access Control Over SSH

What Gitolite Solves and Who It Is For

Git's built-in access control is binary: a user can push or cannot. There is no native mechanism in Git to say that one developer may create branches but not delete them, or that a junior engineer may push to feature branches but not to master. Gitolite solves this by sitting between SSH and Git, intercepting push and fetch requests and applying a set of rules before passing them through.

The README describes Gitolite as allowing setup of Git hosting on a central server "with very fine-grained access control and many (many!) more powerful features." The target audience is a team or organization that runs its own server, wants to self-host Git repositories, and needs to express access rules more specific than yes or no per repository. This fits internal teams at companies, universities hosting project repositories, or any group that does not want to rely on a third-party hosting service.

Gitolite works entirely over SSH. There is no web interface. Administration happens by editing configuration files and pushing them to a special repository called gitolite-admin. This is the defining characteristic: all access control changes go through Git itself.

Installation: Three Steps on a Dedicated Unix Account

Gitolite requires a dedicated userid on a Unix server with specific prerequisites. The README lists them: any Unix system, sh, git 1.6.6 or later, Perl 5.8.8 or later, openssh 5.0 or later, and a userid that currently has no SSH public key-based access. The README recommends that this userid have shell access only via `su - git` from another account on the same server.

Installation is three steps. First, prepare the SSH key: log in to the git account on the server, ensure ~/.ssh/authorized_keys is empty or nonexistent, and copy your workstation's SSH public key as $HOME/YourName.pub. Then clone and install gitolite:

git clone https://github.com/sitaramc/gitolite
mkdir -p $HOME/bin
gitolite/install -to $HOME/bin

Finally, run setup to initialize with yourself as the first administrator:

gitolite setup -pk YourName.pub

If `bin` is not in the PATH, use the full path:

$HOME/bin/gitolite setup -pk YourName.pub

After setup, a gitolite-admin repository is created on the server, and the administrator's workstation can clone it with `git clone git@host:gitolite-admin`. The README is direct about a diagnostic: if you are asked for a password at any point during setup or cloning, something has gone wrong with the SSH key configuration.

Access Rules: R, RW, and RW+ Per Branch and Tag

Access rules in Gitolite live in `conf/gitolite.conf` inside the gitolite-admin repository. Each rule specifies a permission level for a user or group against a repository or a specific ref pattern. The README gives a detailed example:

repo foo
    RW+                     =   alice
    -   master              =   bob
    -   refs/tags/v[0-9]    =   bob
    RW                      =   bob
    RW  refs/tags/v[0-9]    =   carol
    R                       =   dave

This rule set says: alice can do anything to any branch or tag, including rewinding history. Bob can create or fast-forward push to any branch except master and create any tag not starting with `v` followed by a digit. Carol can create version tags. Dave can only clone and fetch. The deny rules (starting with `-`) are evaluated before the permission rules, allowing fine-grained restrictions for specific ref patterns while still granting broader access elsewhere.

Rules are checked in order. The `-` entries do not match the entire repository; they match specific ref patterns. This layered approach gives administrators expressive control over what each developer can do without requiring a separate repository per permission combination.

Groups and the gitolite-admin Push Workflow

Gitolite supports group definitions to avoid repeating user lists across repositories. The README example:

@staff      =   alice bob carol
@interns    =   ashok

repo secret
    RW      =   @staff

repo foss
    RW+     =   @staff
    RW      =   @interns

Group lists accumulate: adding `@staff` in two separate lines has the same effect as listing all members in one line. Groups can also reference other groups: `@all-devs = @staff @interns` creates a combined group. The special group `@all` matches all users or all repositories.

Adding a new user requires copying their SSH public key to the keydir/ subdirectory of the gitolite-admin repository, naming it username.pub, adding them to the relevant repositories in conf/gitolite.conf, committing both changes, and pushing. The push triggers Gitolite to add the new key to ~/.ssh/authorized_keys on the server and create any new repositories listed in the config. The README states explicitly: do not add new repos or users manually on the server. All administration goes through the gitolite-admin push workflow.

Users can check what repositories they have access to with `ssh git@host info`.

Limitations: No Web Interface, No Pull Requests, No Self-Service

Gitolite provides no web interface. There is no way to browse repository contents, view commit graphs, or comment on code through a browser. An administrator manages everything through text files pushed to gitolite-admin, and users interact solely through Git over SSH.

There is no pull request or code review workflow. Gitolite controls who can push where; it has no concept of a proposed change waiting for review. Teams that need code review before merging would need to add a separate tool or adopt a different platform entirely.

User self-service is absent. Adding a new user requires the administrator to add the SSH key to keydir/ and push. There is no portal where a new team member can register their own key. This is appropriate for small teams with a dedicated admin but becomes a bottleneck as the team grows.

Gitolite does not track branch heads or provide notifications. There is no equivalent of GitHub's webhook system built in; triggering CI or sending notifications on push requires configuring Git server-side hooks separately.

The README also notes that Gitolite's complete documentation is at gitolite.com/gitolite, not in the repository itself. The README in the repository covers only SSH-based fresh installation. Running Gitolite over HTTP, migrating from older versions, and advanced features all require consulting the external documentation.

Gitolite vs Gitea: Different Scope, Different Audience

Gitea is a self-hosted Git service with a web interface, user registration, issue tracking, pull requests, and organization management. It stores repositories on the filesystem using Git, similar to Gitolite, but wraps the entire workflow in a GitHub-style web application.

Gitolite and Gitea differ in the administrative model. Gitolite is configured through a text file pushed via Git; every change is itself a commit with a history. Gitea is configured through a web admin panel and a database. Gitolite imposes no storage overhead beyond Git itself and a Perl interpreter; Gitea requires a running web server, a database backend, and significantly more memory.

The choice between them depends on what the team needs beyond repository access. If the team only needs controlled Git push and fetch over SSH, Gitolite is lower overhead. If the team needs a user-facing web interface, issues, or pull requests, Gitea provides all of that at the cost of a more complex deployment.

Maintenance and License

Gitolite was created by Sitaram Chanamougam and remains the primary maintainer. The repository has no GitHub releases; version information and changelogs are in the CHANGELOG file in the root directory. The last push to the repository was on 2026-08-08. The project homepage is the GitHub wiki at github.com/sitaramc/gitolite/wiki, which points to the full documentation at gitolite.com/gitolite for anything beyond the basic README.

Gitolite is licensed under the GNU General Public License version 2. For organizations using Gitolite internally on their own servers without distributing it, the GPL-2.0 places no practical obligations. Any organization that modifies Gitolite and distributes those modifications to users outside their organization must provide the source code under GPL-2.0. The COPYING file in the repository contains the full license text.

Editorial conclusion

Gitolite is the right tool for a team that needs Git hosting on a server they control and wants rule-based access control per repository and per branch, without adopting a full web-based platform. It is a poor fit for teams that need a code review workflow, a web interface for browsing repositories, or user self-service for account management. Before setting it up, verify that you have a dedicated userid on a Unix server with sshd running, that your team members are familiar with SSH key management, and that no existing authorized_keys entries will be disrupted. The GPL-2.0 license restricts redistribution of modifications but places no burden on organizations using Gitolite internally.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. sitaramc/gitolite on GitHub