Important Features of Gitolite

Exclusive offer: get 50% off this eBook here
Gitolite Essentials

Gitolite Essentials — Save 50%

Leverage powerful branch and user access control with Git for your own private collaborative repositories with this book and ebook

£11.99    £6.00
by Sitaram Chamarty | April 2014 | Open Source

In this article by Sitaram Chamarty, the author of Gitolite Essentials, we will learn about Access Control with Gitolite. We will go through sampling of Gitolite's power features, and also understand Gitolite and the Git control flow.

(For more resources related to this topic, see here.)

Access Control example with Gitolite

We will see how simple Access Control can be with Gitolite. First, here's an example where the junior developers (let's call them Alice and Bob here) should be prevented from rewinding or deleting any branches, while the senior developers (Carol and David) are allowed to do so:

Gitolite uses a plain text file to specify the configuration, and these access rules are placed in that file.

repo foo   RW    =  alice bob   RW+   =  carol david

You probably guessed that the RW stands for read and write. The + in the second rule stands for force, just as it does in the push command, and allows you to rewind or delete a branch.

Now, suppose we want the junior developers to have some specific set of branches that they should be allowed to rewind or delete, a sort of "sandbox", if you will. The following command will help you to implement that:

RW+  sandbox/  =  alice bob

Alice and Bob can now push, rewind, or delete any branches whose names start with sandbox/.

Access Control at the repository level is even easier, and you may even have guessed what that looks like:

repo foo     RW+     =   alice     R       =   bob repo bar     RW+     =   bob     R       =   alice repo baz     RW+     =   carol     R       =   alice bob

As you can see, you have three users with different access permissions for each of the three repositories. Doing this using the file systems' permissions mechanisms or POSIX ACLs would be doable, but quite cumbersome to set up and to audit/review.

Sampling of Gitolite's power features

The access control examples show the most commonly used feature of Gitolite, the repository and branch level access control, but of course Gitolite has many more features. In this article, we will briefly look at a few of them.

Creating groups

Gitolite allows you to create groups of users or repositories for convenience. Think back to Alice and Bob, our junior developers. Let's say you had several rules that Alice and Bob needed to be mentioned in. Clearly, this is too cumbersome; every time a new developer joined the team, you'd have to change all the rules to add him or her.

Gitolite lets you do this by using the following command:

@junior-devs    =  alice bob

Later, it lets you do this by using the following command:

repo foo   RW                       =  @junior-devs   RW+                      =  carol david   RW+  sandbox/            =  @junior-devs

This allows you to add the junior developer in just one place at the top of the configuration file instead of potentially several places all over. More importantly, from the administrator's point of view, it serves as excellent documentation for the rules themselves; isn't it easier to reason about the rules when a descriptive group name is used rather than actual usernames?

Personal branches

Gitolite allows the administrator to give each developer a unique set of branches, called personal branches, that only he or she can create, push, or delete. This is a very convenient way to allow quick backups of work-in-progress branches, or share code for preliminary review.

We saw how the sandbox area was defined:

  RW+  sandbox/  =  alice bob

However, this does nothing to prevent one junior developer from accidentally wiping out another's branches. For example, Alice could delete a branch called sandbox/bob/work that Bob may have pushed. You can use the special word USER as a directory name to solve this problem:

  RW+  sandbox/USER/  =  alice bob

This works as if you had specified each user individually, like this:

  RW+  sandbox/alice/   =  alice   RW+  sandbox/bob/     =  bob

Now, the set of branches that Alice is allowed to push is limited to those starting with sandbox/alice/, and she can no longer push or delete a branch called, say, sandbox/bob/work.

Personal repositories

With Gitolite, the administrator can choose to let the user create their own repositories, in addition to the ones that the administrator themselves creates. For this example, ignore the syntax and just focus on the functionality:

repo dev/CREATOR/[a-z].*   C       =  @staff   RW+     =  CREATOR

This allows members of the @staff group to create repositories whose names match the pattern supplied, which just means dev/<username>/<anything starting with a lowercase alphabetic character>. For example, a user called alice will be able to create repositories such as dev/alice/foo and dev/alice/bar.

Gitolite and the Git control flow

Conceptually, Gitolite is a very simple program. To see how it controls access to a Git repository, let us first look at how control flows from the client to the server in a normal git operation (say git fetch) when using plain ssh :

When the user executes a git clone, fetch, or push, the Git client invokes ssh, passing it a command (either git-upload-pack or git-receive-pack, depending on whether the user is reading or writing). The local ssh client passes this to the server, and assuming authentication succeeds, that command gets executed on the server.

With Gitolite installed, the ssh daemon does not invoke the git-upload-pack or git-receive-pack directly. Instead, it calls a program called gitolite-shell, which changes the control flow as follows:

First, notice that nothing changes on the Git client side in anyway; the changes are only on the server side. In fact, unless an access violation happens and an error message needs to be sent to the user, the user may not even know that Gitolite is installed!

Second, notice the red link from Gitolite's shell program to the git-upload-pack program. This call does not happen if Gitolite determines that the user does not have the appropriate access to the repo concerned. This access check happens for both read (that is, git fetch and git clone commands) and write (git push) operations; although for writes, there are more checks that happen later.


In this article, we learned about Access control with Gitolite. We also went through sampling of Gitolite's power features. We also covered the Git control flow.

Resources for Article:

Further resources on this subject:

Gitolite Essentials Leverage powerful branch and user access control with Git for your own private collaborative repositories with this book and ebook
Published: April 2014
eBook Price: £11.99
Book Price: £18.99
See more
Select your format and quantity:

About the Author :

Sitaram Chamarty

Sitaram Chamarty has been in the software industry for a number of years. He is a Linux and open source evangelist who has sometimes been called an "open source bigot", which he takes as a compliment. He loves Perl enough to believe, or at least insist, that xkcd 224 is actual fact.

His day job is with Tata Consultancy Services, and he lives and works in Hyderabad, India. His job does not explicitly include evangelizing open source in general and Git in particular, but he pretends it does. He has signifi cant past experience in language conversion and tools, as well as in data warehousing.

He has a postgraduate degree in Computer Science from the Indian Statistical Institute, Kolkata, India.

Books From Packt

Cloning Internet Applications with Ruby
Cloning Internet Applications with Ruby

GitLab Repository Management
GitLab Repository Management

Instant RubyMotion App Development
Instant RubyMotion App Development

Learning Gerrit Code Review
Learning Gerrit Code Review

Building Dynamic Web 2.0 Websites with Ruby on Rails
Building Dynamic Web 2.0 Websites with Ruby on Rails

Ruby and MongoDB Web Development Beginner's Guide
Ruby and MongoDB Web Development Beginner's Guide

Git: Version Control for Everyone
Git: Version Control for Everyone

Instant RubyMine Assimilation
Instant RubyMine Assimilation

Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software