2011-07-15 11 views
10

Cuando consideramos pasar de SVN a git en el trabajo, un compañero de trabajo ha planteado la preocupación de que un desarrollador malintencionado o propenso a accidentes pueda usar git rebase para eliminar el historial remoto de nuestro repositorio compartido.¿Puede la base de git quitar por completo el historial remoto?

Editar: Como se señala en las respuestas, las sucursales completas también se pueden eliminar del repositorio remoto con git push origin :branch-name.

¿Es esto un problema realista? Si es así, ¿qué enfoque podemos tomar para prevenirlo?

+0

@sehe Esto no soluciona el problema de error humano, y hace que la adopción de git sea un problema organizativo y técnico. –

+0

¿Hay algún punto que estés haciendo? La adopción de un flujo de trabajo VCS es un desafío organizativo. Además, me parece gracioso que lo digas así _después de aceptar_ una respuesta que dice lo mismo ** y ** propone usar a Gerrit para moderar el acceso de inserción ... el 8 de agosto de – sehe

+0

El punto que estoy diciendo es que " tienes que confiar en cada desarrollador individual, o tener guardianes, y nadie nunca cometerá un error "no es realmente una respuesta satisfactoria para la pregunta de mi (compañero de trabajo). Había aceptado una respuesta que decía más o menos eso, asumiendo que era la única solución, pero varias semanas después se sugirió un enfoque diferente. Probaré el enfoque de configuración de parámetros y, si tiene éxito, sería mi respuesta preferida. –

Respuesta

6

estoy de acuerdo con su compañero de trabajo que no es un problema aquí porque:

  • no importa lo bien que confía en sus committers, siempre hay una posibilidad de error humano
  • procesos de revisión más onerosas (por ejemplo, Gerrit) no son siempre apropiadas
  • restaurar las copias de seguridad puede ser lento y un PITA

¿ha considerado la receive.denyNonFastForwards y receive.denyDeletes parámetros de configuración? AFAICT estos están disponibles en Git 1.6 en adelante.

De Pro Git:

Si rebase se compromete a que ya se ha empujado y luego intenta empujar de nuevo, o de otro modo tratar de empujar una confirmación a una rama remota que no contiene la confirmación que actualmente señala la sucursal remota, , será denegada.Esta es generalmente una buena política; pero en el caso de la rebase, puede determinar que sabe lo que está haciendo y puede forzar la actualización de la rama remota con un indicador -f a su comando de inserción.

Para deshabilitar la capacidad de forzar-actualizar las sucursales remotas a referencias no avance rápido, ajuste receive.denyNonFastForwards

La otra manera de hacer esto es a través del lado del servidor recibir ganchos, que me Cubriré un poco. Ese enfoque le permite hacer cosas más complejas como negar el acceso no rápido a un cierto subconjunto de usuarios.

A medida que el autor menciona, esta regla también puede hacerse cumplir por medio de un gancho de recepción (que es described later in Pro Git).

Estas técnicas deben proteger contra el historial perdido accidental (o malicioso) en su repositorio compartido.

+0

Esta sería una buena solución para nosotros, pero estoy nervioso por aceptarla como completa. Dadas las diferentes formas en que se puede usar git, aún podría haber agujeros que permitan la eliminación del código. –

+1

OK, hemos implementado denyNonFastForwards y funciona bien :) –

3

El historial se puede arruinar utilizando rebase, pero normalmente el repositorio remoto no aceptará el cambio que modifica el historial (a menos que use git push --force), pero aún más, el desarrollador con permiso de inserción puede eliminar la rama completamente (origen de git push: nombre de rama). Entonces las reglas simples son:

  • No dejes pasar el permiso a los desarrolladores en los que no confíes.

  • Cuando se comparte el repositorio, no te metas con un historial, evita usar rebase en las confirmaciones pasadas. Utilice merge o cherry-pick en su lugar si necesita agregar algo de una rama diferente, en cuyo caso el historial no se verá afectado.

  • Puede mantener la política de no usar 'push -f' en el repositorio compartido, en cuyo caso el desarrollador sabrá que si se rechaza el push, algo sale mal (lo más probable es que la sucursal local no esté actualizada con el control remoto) y debería resolver el problema localmente en lugar de forzar el empuje.

cuanto a su pregunta de cómo prevenir - utilizar Gerrit sistema de revisión, es como un paso intermedio en el camino del compromiso entre el repositorio y maestro local de recompra de desarrollador con una bonita interfaz web para la revisión, puede dar permisos a envíe el repositorio de revisión a cualquier persona, pero el cambio se fusionará en su rama principal después de la verificación y aprobación (que requieren algunos permisos que normalmente otorga a los desarrolladores principales). Puede ver cómo se ve en el proyecto Mahara: https://reviews.mahara.org En este caso particular, solo bot de gerrit puede presionar al maestro (que es here) y nadie más.

1

Existen extensiones para servidores Git empresariales como Gerrit que detectarán reescrituras de historial y eliminaciones de bifurcaciones, las respaldarán con una referencia especial para que puedan restaurarse si es necesario y no se eliminarán con la recolección de elementos no utilizados. Los administradores de Gerrit aún pueden eliminar confirmaciones seleccionadas si es necesario por razones legales.

Cuestiones relacionadas