remove - No puedo presionar a GitHub debido a un archivo grande que ya eliminé

github tags

Question

Actualmente tengo

1. Repo vacío de GitHub
2. Repo de servidor SSH (principal)
3. Repo local

Repo del servidor SSH fue el repositorio más actualizado (sitio de producción), así que hice un clon de Git desde allí a local. Luego intenté hacer un git push para GitHub.

Todo fue bien, pero luego dijo algo sobre filename.gz que es demasiado grande para GitHub. No necesitaba este archivo, así que ejecuté varios comandos de Git para deshacerme de él desde la memoria caché de Git y luego lo devolví al servidor SSH.

No veo el archivo grande localmente pero todavía está en el servidor SSH a pesar de que git diff no devuelve nada y git push devuelve "Todo está actualizado" - Y a pesar de que el archivo no está visible en el repositorio local cuando intento presionar a GitHub sigo recibiendo un error al respecto

remote: error: El archivo fpss.tar.gz tiene 135.17 MB; esto excede el límite de tamaño de archivo de GitHub de 100 MB

Seguí los pasos en "solucionar el problema" enumerados en la ayuda de GitHub, ¿no debería haber sido suficiente?

¿Cómo está el archivo aún en el éter cuando no es local o aparece en git status / diff / push?

Answer 1

¿Por qué GitHub rechaza mi repositorio, incluso después de que eliminé el archivo grande?

Git almacena el historial completo de tu proyecto, por lo que incluso si "borras" un archivo de tu proyecto, el repositorio de Git aún tiene una copia del archivo en su historial, y si tratas de enviarlo a otro repositorio (como uno alojado en GitHub) luego, Git requiere que el repositorio remoto tenga la misma historia que su repositorio local (es decir, los mismos archivos grandes en su historial).

¿Cómo puedo hacer que GitHub acepte mi repositorio?

Debe limpiar el historial de Git de su proyecto localmente, eliminar los archivos grandes no deseados de todo el historial y luego usar solo el historial "limpio" en el futuro. Los id. De commit de Git cambiarán.

¿Cómo limpio archivos grandes de mi repositorio de Git?

La mejor herramienta para limpiar archivos grandes no deseados de la historia de Git es el BFG Repo-Cleaner : es una alternativa más simple y más rápida a git-filter-branch específicamente diseñada para eliminar archivos no deseados del historial de Git.

Siga cuidadosamente las instrucciones de uso , la parte central es solo esto:

$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

Cualquier archivo de más de 100 MB de tamaño (que no esté en su última confirmación) se eliminará del historial de su repositorio de Git. A continuación, puede usar git gc para limpiar los datos muertos:

$ git gc --prune=now --aggressive

El BFG suele ser al menos 10-50x más rápido que ejecutar git-filter-branch , y generalmente es mucho más fácil de usar.

Descripción completa: soy el autor de BFG Repo-Cleaner.

Answer 2

Encontré squashing más útil que filter-branch de filter-branch . Hice lo siguiente:

1. Eliminar localmente archivos grandes
2. Confirmar las eliminaciones locales.
3. git reset --soft HEAD~3 vuelta X cantidad de confirmaciones (para mí fue 3): git reset --soft HEAD~3
4. Luego vuelve a comprometer todos los cambios (AKA squash) git commit -m "New message for the combined commit"
5. Empuje la confirmación aplastada.

Answer 3

Puedes usar

git filter-branch --index-filter ''git rm -r --cached --ignore-unmatch <file/dir>'' HEAD

Esto eliminará todo en el historial de ese archivo. El problema es que el archivo está presente en el historial.

Answer 4

Si el archivo se agregó con la confirmación más reciente y no se ha enviado a GitHub , puede eliminar el archivo y modificar la confirmación, tomada desde here :

git rm --cached giant_file
# Stage our giant file for removal, but leave it on disk
git commit --amend -CHEAD
# Amend the previous commit with your change
# Simply making a new commit won''t work, as you need
# to remove the file from the unpushed history as well
git push
# Push our rewritten, smaller commit

Answer 5

Tengo el mismo problema y ninguna de las respuestas funciona para mí. Lo resolví por los siguientes pasos:

1. Encuentra qué commit (s) contiene el archivo grande

git log --all -- ''large_file`

El compromiso inferior es el compromiso más antiguo en la lista de resultados.

2. Encuentra el que está justo antes del más antiguo.

git log

Supongamos que tienes:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git rebase

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

Consejos :

1. Artículo de lista
2. Solo elijo drop for the commits contiene el archivo grande.
3. Puede encontrar conflictos durante la reparación de rebase y usar git rebase --continue para continuar hasta que lo termine.
4. Si algo salió mal durante la rebase usa git rebase --abort para cancelarlo.

Answer 6

Tuve un problema similar y usé el paso anterior para eliminar el archivo. Funcionó perfectamente.

Luego recibí un error en un segundo archivo que necesitaba eliminar: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub''s file size limit of 100.00 MB remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub''s file size limit of 100.00 MB

Intenté el mismo paso, recibí un error: "A previous backup already exists in <path/filename>"

De la investigación en este sitio web utilicé el comando: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all

Funcionó muy bien, y los archivos grandes fueron eliminados.

Increíblemente, la inserción todavía falló con otro error: error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly

Esto lo arreglé modificando directamente el archivo de configuración .git - postBuffer = 999999999

¡Después de eso el empujón pasó!