2011-03-14 11 views
7

Alguien en mi equipo envió un archivo grande al servidor git y todos en el equipo ahora tienen una clonación del proyecto con el archivo grande.Cómo eliminar archivos grandes de forma permanente para todo el equipo

Seguí la guía en http://help.github.com/removing-sensitive-data/ y funciona tanto en mi árbol de fuentes local como en el servidor remoto. Pero una vez que otra persona obtiene los datos nuevos del servidor remoto, volverá a introducir fácilmente el archivo grande presionando nuevas confirmaciones en el servidor.

Normalmente, un miembro del equipo hará lo siguiente para compartir su compromiso con los demás:

git fetch origin 
git rebase origin/master 
git push origin 

En el paso de 'rebase', el archivo grande de edad se vuelve a introducir en sus commits locales. Por supuesto, una forma directa es exigir a todos en el equipo que vuelvan a clonar el proyecto después de eliminar el archivo grande, pero no todos estarían felices de hacerlo. Estoy encontrando otra forma que no sea volver a clonar el proyecto completo para todos.

¿Alguna sugerencia? Gracias.

+0

No veo cómo van a introducir el objeto gigante si empujan de nuevo. Un empuje solo empuja a los objetos alcanzables por las confirmaciones que se encuentran en cualquiera de las confirmaciones que están en el old_commit..new_commit. –

+0

Supongamos que tiene un historial de confirmación A-B-C-D-E. Algún tipo agrega el objeto grande en la confirmación C. A continuación, elimino el objeto, reescribo el historial de C y paso el nuevo historial al servidor por la fuerza. La historia ahora es A-B-C'-D'-E '. Otro miembro ya ha clonado todo el proyecto al principio y su historia local también es A-B-C-D-E. Después de recuperar el nuevo historial, las confirmaciones locales divergieron, es decir, A-B-C'-D'-E 'en origen/maestro, mientras que A-B-C-D-E en la rama maestra. Después de la rebase, la nueva historia es como A-B-C'-D'-E'-C-D-E, luego él empuja al servidor - se reintroduce el antiguo compromiso C. –

Respuesta

0

Si el tiempo de ejecución para eliminar el archivo grande es razonable, puede escribir un script que eliminará el archivo, instruir a todos para que ejecuten el script localmente después de una rebase y usar un enlace para verificar que no se reintroduce.

3

eche un vistazo al árbol de filtros. Debe editar la confirmación que introdujo el archivo. Una vez hecho esto, todos pueden buscar. Esto hará que las ramas remotas no avancen en sus repositorios; cada compromiso después de eliminar el archivo ofensivo será diferente ahora. Cuando vuelvan a establecer sus cambios actuales sobre las nuevas sucursales remotas, ya no deberían presionar el objeto grande.

Una alternativa es hacer un git rebase --preserve-merges -i donde edita la confirmación ofensiva.

+0

> "Cuando vuelven a calcular sus cambios actuales sobre las nuevas sucursales remotas, ya no deberían presionar el objeto grande". Esa es mi pregunta, de hecho reintrodujeron nuevamente el archivo después de la rebase, ya que los commits antiguos todavía existen en su repositorio local. –

+0

si el control remoto se limpia, haga que se clonen de nuevo. –

+0

Lo sé, pero estoy buscando otra forma en lugar de clonarlo de nuevo. –

0

El libro de progit tiene un elaborado ejemplo que usa git filter-branch (no el árbol de filtros como se menciona en la otra publicación). El capítulo está aquí

'Eliminación de objetos' http://progit.org/book/ch9-7.html

+0

La guía en el libro de progit es la misma que http://help.github.com/removing-sensitive-data/ –

Cuestiones relacionadas