git - rama principal de bloqueo para algunos usuarios?

Me gustaría obligar a otros miembros del equipo a no trabajar en la rama principal, sino en una rama de desarrollo. tenemos un repositorio git central donde empujamos nuestro trabajo. Me gustaría saber si es posible bloquear a los usuarios para que no modifiquen la rama principal, sino que solo permitan que ciertos usuarios lo hagan.git - rama principal de bloqueo para algunos usuarios?

me gustaría tener la siguiente "flujo de trabajo"

desarrollo está siempre hacer solamente con un desarrollo de la rama
la liberación-gerente es responsable de la rama principal y sólo se le permite fusionar cosas de una rama de desarrollo en el maestro y llevarlo a la rama maestra en el repositorio central a.

¿Es esto posible y cómo puedo lograrlo?

Fuente

2010-12-10 aurora

El control de acceso se subcontrata desde git al sistema operativo que ejecuta el servidor. Si está ejecutando su propio servidor, le recomiendo que instale gitosis: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way – blueberryfields

gracias, Echaré un vistazo a la gitosis ... – aurora

Pensé que es exactamente porque 'git' se distribuye, no es necesario controlar los permisos porque no existe un repositorio" compartido ". En otras palabras, cualquier miembro del equipo que trabaje en el proyecto trabajará en su propia copia del repositorio, y es el mantenedor el que fusiona las ramas en un repositorio "maestro" (solo un nombre para que no se confunda con la rama principal). – amn

Ver man githooks: en el repositorio compartido, puede crear un script $(git rev-parse --git-dir)/hooks/pre-receive o $(git rev-parse --git-dir)/hooks/update que verifica qué están intentando impulsar los usuarios a qué referencias. Git viene con un gancho de ejemplo update-paranoid que impone las ACL por ref.

Fuente

2010-12-10 23:35:13 ephemient

gracias ... los githook parecen ser muy poderosos. Echaré un vistazo a gitosis y githooks – aurora

¿Alguien puede ampliar esto? Miré el gancho '[update-paranoid] (http://git.kernel.org/cgit/git/git.git/tree/contrib/hooks/update-paranoid?id=HEAD)', pero estoy no estoy seguro de entender cómo se vería la ACL para múltiples usuarios. ¿Se espera que un usuario tenga múltiples entradas para committers permitidos en el formato: 'committer = John Doe <[email protected]>', y esto podría usarse para N usuarios como: ' committer = John Doe < [email protected]> committer = Usuario2 <[email protected]> committer = Usuario3 <[email protected]> ' ? – blong

@ b.long: 'update-paranoid' espera un' users/$ {USER} .acl' dentro de '/ vcs/acls.git' repo (no * this * repo) para cada inicio de sesión de SSH; dentro de cada uno, puede haber tantas líneas 'committer =' como se desee. Pero es probable que desee modificar o reescribir el script para su propio uso. – ephemient

Mi enfoque de bajo nivel sería simplemente dejar que el RM sea el único con las teclas SSH para enviar al repositorio que todos los demás usan como línea maestra de referencia. De esa manera, nadie más que el RM puede presionar para dominar, sin embargo, todos pueden trabajar ya que tienen sus propias ramas de desarrollo local y los desarrolladores pueden compartir entre ellos las ramas que les gustan.

El siguiente paso es hacer un probador de ollas de cocina para las cosas que entrarán en el maestro pronto. Este pote normalmente se llama next o dev. La idea es que cuanto más impacto tenga una sucursal, más tiempo cocinará antes de fusionarse para dominar. Esto le da al RM control total sobre las ramas que deberían graduarse y aún les da a todos un aviso.

Fuente

2010-12-11 01:56:18

gracias. Pensé en ssh también y sería bastante fácil de configurar. pero pensé que debería haber 'mejores' formas ...? – aurora

git - rama principal de bloqueo para algunos usuarios?

Respuesta

Cuestiones relacionadas