gitolite: permite cambiar solo los archivos seleccionados

Question

¿Cómo se configura git y gitolite para permitir que un usuario específico cambie solo los archivos que están dentro del directorio específico?

p. Ej. archivos de origen de la rama principal:

/dir1/ 
/dir2/file1 
/dir2/file2 
/dir3/file1 

usuario kathrine, permiten cambiar sólo /dir2/file1 y /dir2/file2

$kathrine: git clone git@example.com:test.git 

resultados en:

/dir2/file1 
/dir2/file2 

¿Existen directivas por-dir en gitolite.conf o ¿debo configurar git con una nueva rama para este usuario?

Simplemente no quiero que el diseñador de gráficos tenga acceso a los archivos de código fuente.

Answer 1

2010: Para Gitolite 2 (podría haber cambiado para gitolite 3)

No (es decir, una rama dedicada con el contenido correcto se debe crear).

A medida que el author of gitolite himself put it:

yo soy el autor de un proyecto llamado gitolite que hace un excelente trabajo de control de acceso a nivel de rama de múltiples repositorios Git en un servidor central. Mi "mercado" objetivo es precisamente usuarios corporativos de git.

Hasta ahora, no he visto una situación donde de acceso de lectura debe estar restringido a las oraciones de un repositorio (de todos modos, Git no puede hacer eso).

[así sparse checkout podría ayudar, pero no es fácil de todos modos)

acceso de escritura no necesitan a menudo ser restringido, y gitolite puede dejar que se restringe:

• tanto por nombre de la sucursal (por ejemplo, solo el líder de QA puede insertar una serie de commit en la rama "QA-done")
• o por nombre de archivo (por ejemplo, solo el jefe del equipo puede realizar cambios en el archivo Makefile en src/very-important-and-critical-module)

---

Vea la sección "security, access control, and auditing", y aquí es un ejemplo de escritura acceso:

El conf/example.conf file tiene toda la sintaxis detallada:

repo foo 
     RW+ = lead_dev # rule 1 
     RW = dev1 dev2 dev3 dev4 # rule 2 

     RW NAME/ = lead_dev # rule 3 
     RW NAME/doc/ = dev1 dev2 # rule 4 
     RW NAME/src/ = dev1 dev2 dev3 dev4 # rule 5 

cada archivo tou ched por los commits que se empujan se compara con esas reglas.

• lead_dev puede empujar los cambios en los archivos,
• dev1/2 puede empujar cambios en los archivos en "doc/" y "src/" (pero no el nivel superior README),
• y dev3/4 puede solo envía cambios a los archivos en "src/".

---

Dicho esto, la pregunta difícil sigue siendo, como la OP pone:

¿Cómo se crea nueva bruja rama sólo algunos archivos seleccionados y eliminar las confirmaciones anteriores, para que el diseñador gráfico no pueda acceder a ellos y vea solo los seleccionados después del clon?

Principio general:

crear rama 'graph_designer' en un punto de la historia en esos archivos no estaban presentes.

A partir de ahí, dos opciones:

• ya sea reorganizan sus confirmaciones de corriente (git rebase --interactive) con el fin de tener primero el que tiene sólo dir2 archivos (y después comete impactar cualquier otro directorio)
• o, si la primera opción representa demasiado trabajo (o no es posible porque esas confirmaciones ya han sido empujadas y tiradas en otros repositorios), simplemente copie y agregue los archivos relevantes en esa nueva rama.
  Eso significa que no hay historial para esos archivos, pero es posible que no necesiten ese historial desde el principio.

Que 'graph_designer' será la única rama permitida para ser clonada, y no contendrá ningún historial con archivos no autorizados.