Actuellement j’ai
Le référentiel de serveur SSH était le plus à jour (site de production). J’ai donc fait un clone de Git en local. J’ai ensuite essayé de faire une git push
vers GitHub.
Tout s’est bien passé, mais le fichier filename.gz était trop gros pour GitHub. Je n’avais pas besoin de ce fichier, j’ai donc lancé plusieurs commandes Git pour les éliminer du cache Git, puis les renvoyer sur le serveur SSH.
Je ne vois pas le gros fichier localement mais il est toujours sur le serveur SSH même si git diff
ne retourne rien et que git push renvoie “Tout est à jour” – Et même si le fichier n’est pas visible dans le repo local quand j’essaye de pousser à GitHub J’ai toujours une erreur à ce sujet
remote: error: Le fichier fpss.tar.gz est 135,17 Mo; ceci dépasse la limite de taille de fichier de GitHub de 100 Mo
J’ai suivi les étapes sous “résoudre le problème” répertorié dans l’aide de GitHub, alors cela ne devrait-il pas suffire?
Comment le fichier se trouve-t-il toujours dans l’éther lorsqu’il n’est pas local ou qu’il est répertorié dans git status / diff / push?
Vous pouvez utiliser
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch ' HEAD
Cela supprimera tout dans l’historique de ce fichier. Le problème est que le fichier est présent dans l’historique.
Si le fichier a été ajouté avec votre dernière validation et que vous n’avez pas accédé à GitHub , vous pouvez supprimer le fichier et modifier la validation.
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
J’ai eu un problème similaire et j’ai utilisé l’ étape ci-dessus pour supprimer le fichier. Cela a parfaitement fonctionné.
J’ai ensuite reçu une erreur sur un second fichier que je devais supprimer: remote: error: File
remote: error: File
J’ai essayé la même étape, j’ai reçu une erreur: "A previous backup already exists in
De recherches sur ce site, j’ai utilisé la commande: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch
Travaillé très bien et les gros fichiers ont été supprimés.
Incroyablement, la poussée a encore échoué avec une autre erreur: 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
Ce que j’ai corrigé en modifiant directement le fichier de configuration postBuffer = 999999999
– postBuffer = 999999999
Après cela, la poussée est passée!
J’ai trouvé le squashing plus utile que filter-branch
. J’ai fait ce qui suit:
git reset --soft HEAD~3
retour X nombre de commits (pour moi c’était 3): git reset --soft HEAD~3
git commit -m "New message for the combined commit"
Git stocke l’historique complet de votre projet, donc même si vous “supprimez” un fichier de votre projet, le repository Git a toujours une copie du fichier dans son historique, et si vous essayez de pousser vers un autre référentiel GitHub) alors Git requirejs que le repo distant ait le même historique que votre repo local (c’est-à-dire les mêmes gros fichiers dans son historique).
Vous devez nettoyer l’historique Git de votre projet localement, en supprimant les fichiers volumineux indésirables de l’historique, puis n’utiliser que l’historique “nettoyé”. Les identifiants de validation Git des validations affectées changeront.
Le meilleur outil pour nettoyer les fichiers volumineux indésirables de l’historique de Git est le Repo-Cleaner de BFG .
Suivez attentivement les instructions d’utilisation , l’essentiel est juste ceci:
$ java -jar bfg.jar --ssortingp-blobs-bigger-than 100M my-repo.git
Tous les fichiers de taille supérieure à 100 Mo (qui ne figurent pas dans votre dernier commit) seront supprimés de l’historique de votre repository Git. Vous pouvez ensuite utiliser git gc
pour nettoyer les données mortes:
$ git gc --prune=now --aggressive
Le BFG est généralement au moins 10 à 50 fois plus rapide que l’exécution de git-filter-branch
, et généralement beaucoup plus facile à utiliser.
Divulgation complète: je suis l’auteur du Repo-Cleaner BFG.
J’ai le même problème et aucune des réponses ne fonctionne pour moi. J’ai résolu par les étapes suivantes:
git log --all -- 'large_file`
La validation inférieure est la validation la plus ancienne de la liste de résultats.
git log
Supposons que vous ayez:
commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
Astuces :
drop
pour les commits contient le gros fichier. git rebase --continue
continuez jusqu’à ce que vous ayez fini. git rebase --abort
pour l’annuler.