Git: múltiples usuarios que usan el mismo directory de trabajo: problemas de permissions en los metafiles .git

El problema: cuando varios usuarios tienen acceso al mismo directory de trabajo, pueden ocurrir problemas de permissions en los metadatos si se realizan operaciones de git .

DESCARGO DE RESPONSABILIDAD : Antes de castigarme, me doy count de que compartir un directory de trabajo es contrario a lo que significa Git, y no estoy hablando de hacer nada más que operaciones de solo lectura en este directory compartido. Hacemos todo nuestro trabajo en nuestros repositorys locales .

Estoy abierto a sugerencias sobre otra forma de hacer lo que estamos tratando de hacer, ya que nuestro enfoque no es la mejor práctica, pero no estoy seguro de que la conversación sea útil para que otros la escuchen. Así que por ahora permítanme proporcionar algunos detalles sobre por qué estamos haciendo esto:

Tenemos varios maestros de construcción en nuestro equipo. Implementamos en serveres Linux, y hacemos nuestras construcciones allí, con scripts de compilation que se obtienen directamente de Git. No podemos usar CI (como Jenkins / cruisecontrol) en este momento, por lo que tenemos un repository que procesamos y realizamos nuestras versiones de QA.

Hay algunas operaciones de git que realizamos como parte de la secuencia de commands. Esto incluye algunos labeldos de confirmaciones (las cosas se labeln como QA-current, QA-previous, etc …). Así que supongo que no somos en realidad solo de lectura. Debido a la naturaleza del script de construcción, lo ejecutamos como un usuario común (llamemos a ese usuario DevAdmin). Me doy count de que esto podría ser una mala práctica, y tal vez sea la fuente del dolor, ya que nos obliga a utilizar un process de recompra compartido.

Todo estaría bien, si siempre estuviéramos sudoed en ese directory de trabajo. El problema es que, en ocasiones, uno de nosotros hará un git pull o algo similar por crash, sin ser sudoed como DevAdmin. Así que la mayoría de los files en .git son propiedad de DevAdmin (que realizó el clon inicial), pero cada vez que hacemos esto, terminamos con directorys en .git/objects que contienen files propiedad de un usuario específico. Y estos se crean como grupo no escribible. También he notado ORIG_HEAD con propiedad incorrecta, por ejemplo. Entonces, cuando tratamos de hacer algo como DevAdmin, tenemos problemas.

¿Hay algo que podamos hacer para solucionar este problema? En este momento, debemos reconocer que ha sucedido y luego hacer que un administrador del server vuelva a colocar chown .git en DevAdmin. O haga que el usuario elimine los metafiles en cuestión o, al less, los chmod a escritura de grupo. Todo esto parece muy malo.

He considerado un par de opciones que no implican cambios drásticos en nuestros processs de construcción y mantenimiento:

Si eliminamos el acceso de escritura grupal en .git y lo restringimos a DevAdmin, ¿evitaría que esto vuelva a suceder? Esta parece ser la opción más directa.

¿O hay una manera de hacer que todo en .gi t group-writable, incluso cuando se acaba de crear? Esto parece pedir problemas.

¿Hay algo más obvio que me estoy perdiendo? Me doy count de que lo mejor sería cambiar nuestro process para que los usuarios puedan trabajar en sus propios repositorys, pero en un entorno comercial, los repos pueden ser muy grandes (los files jar no están separados, muchos files binarys, etc. …), y no podemos tener repositorys multi-GB para la count de todos. Además, nuestros administradores de sistemas tendrían mucho trabajo por delante cambiando sus processs para permitirlo.

Cualquier pensamiento es apreciado

Hay varias maneras de abordar este problema. Personalmente, recomendaría lo siguiente en su repository existente:

 # Create a group named "gitshare" that will share the repository. sudo groupadd gitshare # Add yourself and as many others as you want to the group. sudo adduser "$LOGNAME" gitshare # Everything else needs to run from the top level of your Git repository. cd /path/to/repository # Add group permissions for *new* modifications to repository. git init --shanetworking=group # Fix permissions for existing repository objects. chown -R :gitshare "$PWD" chmod -R g+swX "$PWD" 

Obviamente, debe asegurarse de que los usuarios tengan permissions de paso de directory hasta su repository (por ejemplo, los directorys privados pueden causar problemas) y que todos los miembros del equipo que necesitan acceso pertenecen al grupo compartido del repository. Después de esta configuration inicial, sin embargo, debería "funcionar".

Acabo de enfrentar este problema y me tomó horas encontrar la solución cuando era tan simple. Intenté casi todo lo que veo en el otro enlace provisto por CodeGnome.

Estoy usando Centos 6.x y la solución fue cambiar el umask en los usuarios … esto requiere que lo hagamos con cada count … Solo estamos trabajando 2 en el mismo directory. No es mucho dolor.

La solución que funcionó para mí es esta, sin tener que cambiar la configuration del server: http://www.avajava.com/tutorials/lessons/how-do-i-set-the-default-file-and-directory- permissions.html

Si la .bashrc filoe no existe en / home / user directory, como esta en mi caso, solo necesita copyr del esqueleto el file en / ect / skel y luego copyrlo en su directory de inicio (usuarios) después de agregar al final del file:

 umask 002 

Esto le da al usuario un chmod 775 en las nuevas carpetas creadas por otros en el grupo. Por supuesto, una vez que este proyecto se complete, ya no en un entorno de testing, lo estableceremos de nuevo en chmod 755 (umask 022) de forma pnetworkingeterminada. Esto no solo le da permiso a Git para sobrescribir, sino también para escribir files cargados en sFTP sin tener el problema de permiso denegado. .