GIT support for branch based user authorization - Best Practices or Tools?

Question

For a product based GIT repository, wherein there are branches for maintenance, testing as well as future development, how do I control user access to these branches. By access, I mean that even though others may read from it, they should not be able to inadvertently push changes to the repo.

For example,

A - B - C - D - E - F -> master
    |   |       |
    V1  V2'     exp
        |
        V2

"B" is the commit used for Branch with tag V1 - meant for released version of the product. Only support/maintenance engineers should have access to this.

C is used for a recently frozen pre-release product V2' and should only allow critical show-stopper bug fixes, so only certain developers and the Testing team should have access to it. when V2 is released from this branch, only Support should access it as is the case with V1.

E is used for branching off for testing a new feature for future V3 - only developers and not Support should access it.

"master" changes should only be merged on a request basis (similar to say, GitHub) by a central integration team.

How can the above be achieved with git? I recall seeing gitosis and some other external tools - are these essential for secure operation with git or are there any other best practices?

Thanks.

ADDED Gitflow best practice branching model

Bourgeois

What's wrong with using separate repos? People use them all the time on github, pulling as needed. – Seringapatam

@A-B-B separate git repos interfere with the usual branching workflows. Any pointers welcome to other projects who are doing secured branch maintenance using multiple repos, without duplicating commits/merges across multiple named repositories. While anything is possible given enough policies, the goal is to use a standard workflow rather than hacking the tool to suit a process. As I mentioned, this is for a product development, which has many releases, patch sets i.e. v1.0, v1.1, v1.1.0.1, v2.0 etc. – Bourgeois

Enforcing branch based user authorization, i.e. the topic of this question, is akin to hacking the tool. With multiple repos, the enforced security is per repo, not per branch. – Seringapatam

Given the number of other queries around securing branches, as well as the fact that this is a core need for any enterprise product release, I am not sure why a valid need is a hack? A hack is a cheap solution/workaround, so in fact using multiple repos sounds like one. A much more elegant solution is needed and from the answers below it seems there are tools being built to solve this issue with git. – Bourgeois

Forking is a common operation at least for GitHub repos. See the links in the answers to "What is the Fork & Pull Model in GitHub?" – Seringapatam

Answer 1

The other classic way to restrict push access to a repo (or a branch or even a directory) is by using gitolite (which actually is a big evolution of gitosis).

You can define there (in the gitolite config file) any group of users or group of repos you need and associate RW access rights.

---

Note: August 2013:

• Stash provides read-only branches,
• and BitBucket should do the same soon

We've released branch restrictions which can be configured via the repository admin "Branch management" screen.

Assembla provides such a protection as well (since March 2013).

GitHub doesn't have yet this feature:
GitHub has that feature since Sept. 2015: see "How to protect “master” in github?".

Emmetropia

Thanks - gitolite was the other tool I looked at apart from gitosis. But I was wondering if there was a native git capability to do the same. I guess server side commit hooks to manage it (as answered below) is probably one way to do it. – Bourgeois

@rraheja: gitolite implements that feature by using those same server side hooks provided by git. – Bleach

Hi @VonC, I have to use Github, and now i encounter "branch permission" issue, could you give me some suggestions, thank :-) – Tolerate

@RongNK with GitHub, you can start managing permissions through forks: each colloborator can only make pull request, and the owner of the main public repo has full onctrol on which pull request commits go to which branch. No more permission issue there. – Emmetropia

gitolite is awesome for a quick RBAC solution. Heck, once upon a time, I modded it for AD (LDAP) authe and autho: ldapsearch plus well-tested LDAP queries worked flawlessly. – Rennes

Answer 2

Put a server side commit hook that denies commits to whatever branches you need read-only or based on who the committer is.

For merging request work flow, we use a local install of Gitorious and submit merge requests through its web interface and restrict the main-line repository to your integration team, everyone else would work from server side clones and then push merge requests back to the main-line repository.

With Gitorious you don't need the server side hooks, you just need to restrict access to the main-line repository to only the people you want to be committer. Much simpler and easier to maintain.

Jobyna

Thanks - For merging request workflow, did you look at any other native alternative; similar to using server side commit hooks instead of gitosis/gitolite? Say, using server side hooks to block pushes and convert them into email requests instead? – Bourgeois

No, Gitorious, isn't the easiest thing to set up, but once it is working its workflow was picked up my my developers immediately. We have a distributed team 10.5 hours apart, Gitorious makes collaboration extremely easy. – Jobyna