remota - Actualice un equipo de desarrollo con el historial repo de Git repo, eliminando archivos grandes

git push example (4)

Tengo un repositorio git con algunos binarios muy grandes. Ya no los necesito, y no me importa poder verificar los archivos de confirmaciones anteriores. Por lo tanto, para reducir el tamaño del repositorio, quiero eliminar los archivos binarios del historial por completo.

Después de una búsqueda en la web, concluí que mi mejor opción (¿la única?) Es usar git-filter-branch :

git filter-branch --index-filter ''git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip'' HEAD

¿Esto parece un buen enfoque hasta ahora?

Suponiendo que la respuesta es sí, tengo otro problema con el que lidiar. El manual de git tiene esta advertencia :

¡ADVERTENCIA! El historial reescrito tendrá diferentes nombres de objetos para todos los objetos y no convergerá con la rama original. No podrá empujar y distribuir fácilmente la rama reescrita en la parte superior de la rama original. No utilice este comando si no conoce todas las implicaciones, y evite usarlo de todos modos, si una simple confirmación simple fuera suficiente para solucionar su problema. (Consulte la sección "RECUPERACIÓN DE UPSTREAM REBASE" en git-rebase (1) para obtener más información sobre la reescritura del historial publicado).

Tenemos un repositorio remoto en nuestro servidor. Cada desarrollador empuja y tira de él. Basado en la advertencia anterior (y mi entendimiento de cómo funciona git-filter-branch ), no creo que pueda ejecutar git-filter-branch en mi copia local y luego presionar los cambios.

Por lo tanto, estoy tentativamente planeando seguir los siguientes pasos:

Dile a todos mis desarrolladores que se comprometan, presionen y dejen de trabajar un poco.
Inicie sesión en el servidor y ejecute el filtro en el repositorio central.
Haga que todos eliminen sus copias antiguas y clonen nuevamente desde el servidor.

Suena bien? ¿Es esta la mejor solución?

Sí, tu solución funcionará. También tiene otra opción: en lugar de hacer esto en el repositorio central, ejecute el filtro en su clon y luego vuelva a git push --force --all con git push --force --all . Esto obligará al servidor a aceptar las nuevas sucursales de su repositorio. Esto reemplaza el paso 2 solamente; los otros pasos serán los mismos

Si sus desarrolladores son bastante expertos en Git, es posible que no tengan que eliminar sus copias antiguas; por ejemplo, podrían buscar los nuevos controles remotos y volver a ordenar sus ramas de tema según corresponda.

Si no haces que tus desarrolladores vuelvan a clonar, es probable que consigan arrastrar los archivos grandes de nuevo. Por ejemplo, si empalman cuidadosamente en el nuevo historial, crearás y luego pasarás a git merge de una rama de proyecto local. que no se reescribió, los padres del compromiso de fusión incluirán la rama del proyecto que finalmente apunta a la historia completa que usted borró con git filter-branch .

Su plan es bueno (aunque sería mejor realizar el filtrado en un clon desnudo de su repositorio, en lugar de hacerlo en el servidor central), pero con preferencia a git-filter-branch debería usar mi BFG Repo-Cleaner , un más rápido , una alternativa más simple a git-filter-branch diseñada específicamente para eliminar archivos grandes de repositorios Git.

Descargue el Java jar (requiere Java 6 o superior) y ejecute este comando:

$ java -jar bfg.jar --strip-blobs-bigger-than 1MB my-repo.git

Cualquier blob de más de 1MB de tamaño (que no esté en su último commit) será eliminado por completo del historial de su repositorio. A continuación, puede usar git gc para limpiar los datos muertos:

$ git gc --prune=now --aggressive

El BFG suele ser 10-50 veces más rápido que ejecutar git-filter-branch y las opciones se adaptan a estos dos casos de uso comunes:

Eliminando Crazy Big Files
Eliminar contraseñas, credenciales y otros datos privados

Su solución no está completa. Debe incluir --tag-name-filter cat como argumento para filtrar la sucursal de modo que también se modifiquen las etiquetas que contienen los archivos de gran tamaño. También debe modificar todos los refs en lugar de simplemente HEAD, ya que la confirmación podría estar en varias ramas.

Aquí hay un código mejor:

git filter-branch --index-filter ''git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip'' --tag-name-filter cat -- --all

Github tiene una buena guía: https://help.github.com/articles/remove-sensitive-data