On Thu, Aug 15, 2013 at 09:46:49PM -0700, Jimit Modi wrote:
> At our company, we are evaulating to migrate to GIT from SVN. Here we are 
> following a process in which we have the following branch and access 
> control.
> -----------------------------------------------
> | Branch    | Purpose          | ACL          |  
> -----------------------------------------------
> | `master`  | live copy        | AGM          |  
> -----------------------------------------------
> | `staging` | staging copy     | AGM, TL      |
> -----------------------------------------------
> | 'dev`     | development copy | AGM, TL, Devs|
> -----------------------------------------------
> Now all devs create a feature branch from the dev branch and again merge it 
> in dev when they have finished working and push it. Now TL review the work 
> and cherry pick or merge dev in staging, depending on the sencario. If 
> everything is well they push the changes on staging. Same is done by AGM's 
> for master branch.
> We want that devs will be able to pull the changes from staging and master 
> branch, 
> but will not be able to push.
> So the question is:
> - How can we setup a authentication system where only the allowed one will 
> be able to push.?

I gather you can write a hook that allows only certain users to push
changes from `staging` to `master`.  Most likely that sort of script
can already be found in the wild somewhere.

Here's another thought, albeit a wild and crazy one: trust that the
developers understand rules and can follow them.  Just tell them to
never ever push anything from `staging` to `master`.  If you want to
you can monitor them for a while to convince yourself that they can
follow that simple instruction and only if they completely fail can
you start looking at authorization for pushing into certain branches
(or consider whether you really want people around who can't follow
such basic instructions ;-).  Reasons for doing it this way:

  - It almost certainly will work from day one.
  - Git makes it easy to revert any failures to comply with the rule.
  - With this 'social solution' you can much more easily break the
    rule when the need arises.  The day will come when you are facing
    a critical bug, that has to be pushed to `master`, but no-one
    authorized is available.  


Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
     -- Alan Kay

Attachment: pgpQLoZxRDOB5.pgp
Description: PGP signature

Reply via email to