GIT support for branch based user authorization -

问题:

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

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

回答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.