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?

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.

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, which will be explained in a much later chapter, but just focus on the functionality now:

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.