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

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?".