Git deny users to create tags

Here is a question abou开发者_运维技巧t git repo management...

Is it possible to configure git repo to allow TAG creation only for some users? And similar question for branch: is it possible to configure list of user, who are able to modify particular branch?

The idea for all this config is: there is git repo with MANY developers, and we want to have a few stable branches and list of tags. And only senior developers will be able to modify those branches and create tags. All other developers still can create branches and so on. But if developer wants to promote his changes to one of stable branches, he must to contact senior person to ask him to make merge...

thank you

---

Gerrit (mainly a code review system) solves this problem almost exactly as you're describing it.

You define groups, and then set repository permissions on who can push for review in a branch, who can push changes directly to a branch, who can push tags (of various types) and even who can see/push to your top-secret branch.

Our gerrit instance is open to the world, although we do limit who can push what and where (and have some collaborators on some projects who can do more than others).

---

You can limit access using standard file access rules on .git/refs/heads and .git/refs/tags. For example, if you make .git/refs/tags mode 775, then only members of the group that owns .git/refs/tags will be able to make tags. Similarly, you can restrict read permission to .git/refs/heads/foo so that only those with read access will be able to checkout branch foo, and only those with write access to .git/refs/heads will be able to create new branches. This is an unreliable technique, however, and you'd be much better off using distinct repositories with appropriate accesses.

---

For branches and annotated tags (i.e. versioned tags that can be pushed/pulled), gitolite can provide that kind of access control.

See "matching a ref and a refex" (gitolite 3.x)

This kind of tool allows for the protection of "central" repositories: if you have the right credentials, you can clone them and do what you want with your local copy, but as soon as you want to push back, gitolite will control the permissions associated with that remote repo.

If no refex is supplied, it defaults to refs/.*, for example in a rule like this:

RW              =   alice

A refex not starting with refs/ (or VREF/) is assumed to start with refs/heads/.
This means normal branches can be conveniently written like this:

RW  master      =   alice
# becomes 'refs/heads/master' internally

while tags will need to be fully qualified:

RW  refs/tags/v[0-9]    =   bob

---

So by default, you cannot push tags, unless there is an explicit refs/tag/ rule allowing it for your user or group of user.

---

It is my understanding through reading the documentation and personal experience that Git is not designed to be used in that way. What you're describing can easily be handled by a multiple repository scenario in which lesser developers push to a development repository and the senior developers pull changes from that, merge, test, etc... and then deploy to a production repo from which any developer can pull.