web-dev-qa-db-fra.com

Impossible d'envoyer à GitHub à cause d'un fichier volumineux que j'ai déjà supprimé

Actuellement j'ai

  1. Repo vide GitHub
  2. Repo de serveur SSH (principal)
  3. Repo locale

Le référentiel de serveur SSH était le référentiel le plus récent (site de production), aussi j’ai fait un clone Git de là vers local. J'ai ensuite essayé de faire un git Push à GitHub.

Tout s'est bien passé, mais ensuite, il a été dit que filename.gz était trop volumineux pour GitHub. Je n'avais pas besoin de ce fichier, j'ai donc lancé plusieurs commandes Git pour le supprimer du cache Git, puis repoussé sur le serveur SSH.

Je ne vois pas le fichier volumineux localement, mais il est toujours sur le serveur SSH même si git diff ne renvoie rien et git Push renvoie "Tout est à jour" - Et même si le fichier n'est pas visible dans le dépôt local lorsque J'essaie de pousser sur GitHub mais j'ai toujours une erreur

remote: error: Le fichier fpss.tar.gz est égal à 135,17 Mo; cela 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 n'aurait-il pas dû suffire?

Comment le fichier est-il toujours dans l'éther quand il n'est pas local ou listé dans git status/diff/push?

gitgithubgit-push
198
SuperDistros

Vous pouvez utiliser

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

Cela supprimera tout dans l'historique de ce fichier. Le problème est que le fichier est présent dans l'historique.

Cette commande modifie les hachages de vos commits, ce qui peut poser un réel problème, en particulier sur les référentiels partagés. Cela ne devrait pas être fait sans en comprendre les conséquences.

377
MacGyver

Si le fichier a été ajouté avec votre validation la plus récente et que vous n'avez pas poussé vers GitHub , vous pouvez supprimer le fichier et modifier le commit, Tiré de ici :

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
35
BlueMoon93

J'ai trouvé écraser plus utile que filter-branch. J'ai fait ce qui suit:

  1. Supprimer localement les gros fichiers.
  2. Commit les suppressions locales.
  3. Soft reset back X nombre de commits (pour moi c'était 3): git reset --soft HEAD~3.
  4. Puis réengagez tous les changements ensemble (AKA squash) git commit -m "New message for the combined commit"
  5. Poussez écrasé commettre.

Cas particulier (de l'utilisateur @lituo): Si ce qui précède ne fonctionne pas, il se peut que vous ayez ce cas. Commit 1 incluait le fichier volumineux et la validation de Commit 1 avait échoué en raison d'une erreur de fichier volumineux. Commit 2 a supprimé le fichier volumineux de git rm --cached [file_name] mais la validation de la validation 2 a toujours échoué. Vous pouvez suivre les mêmes étapes ci-dessus, mais au lieu d'utiliser HEAD~3, utilisez HEAD~2.

30
But I'm Not A Wrapper Class

J'ai eu un problème similaire et utilisé le étape ci-dessus pour supprimer le fichier. Cela a fonctionné parfaitement.

J'ai ensuite eu une erreur sur un deuxième fichier que je devais supprimer: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB

J'ai essayé la même étape, j'ai eu une erreur: "A previous backup already exists in <path/filename>"

De recherche sur ce site j'ai utilisé la commande: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --Prune-empty --tag-name-filter cat -- --all

A bien fonctionné et les gros fichiers ont été supprimés.

Incroyablement, le Push a quand même é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

J'ai corrigé cela en modifiant directement le fichier de configuration .git - postBuffer = 999999999

Après cela, la Push est passée!

13
Andre Odendaal

Pourquoi GitHub rejette-t-il mon rapport même après avoir supprimé le gros fichier?

Git stocke l'historique complet de votre projet. Ainsi, même si vous supprimez un fichier de votre projet, le référentiel Git en conserve une copie dans son historique, et si vous essayez de transférer vers un autre référentiel (comme celui hébergé sur GitHub) puis Git requiert le référentiel distant a le même historique que votre référentiel local (c.-à-d. Les mêmes gros fichiers dans son historique).

Comment puis-je obtenir que GitHub accepte mon dépôt?

Vous devez nettoyer l'historique Git de votre projet localement, en supprimant les gros fichiers indésirables de l'ensemble de l'historique, puis utiliser uniquement l'historique "nettoyé". Les identifiants de validation Git des validations affectées seront modifiés.

Comment nettoyer les gros fichiers de mon dépôt Git?

Le meilleur outil pour nettoyer les gros fichiers indésirables de l'historique Git est le BFG Repo-Cleaner - c'est une alternative plus simple et plus rapide à git-filter-branch spécialement conçue pour supprimer les fichiers indésirables de l'historique Git.

Suivez attentivement les instructions d'utilisation , la partie principale est juste ceci:

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

Tous les fichiers de plus de 100 Mo (qui ne font pas partie de votre dernier commit ) seront supprimés de l'historique de votre référentiel Git. Vous pouvez ensuite utiliser git gc pour effacer les données mortes:

$ git gc --Prune=now --aggressive

Le BFG est généralement au moins 10-50x 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 BFG Repo-Cleaner.

10
Roberto Tyley

Voici quelque chose que j'ai trouvé très utile si vous avez déjà manipulé votre référant avant de demander de l'aide. Premier type:

git status

Après cela, vous devriez voir quelque chose le long des lignes de

On branch master
Your branch is ahead of 'Origin/master' by 2 commits.
  (use "git Push" to publish your local commits)

nothing to commit, working tree clean

La partie importante est le "2 commits"! De là, allez-y et tapez:

git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>

Donc, pour l'exemple ci-dessus, on pourrait taper:

git reset HEAD~2

Après avoir tapé cela, votre "statut de git" devrait indiquer:

On branch master
Your branch is up to date with 'Origin/master'.

nothing to commit, working tree clean

À partir de là, vous pouvez supprimer le fichier volumineux (en supposant que vous ne l’ayez pas déjà fait) et vous devriez pouvoir tout réengager sans perdre votre travail.
Je sais que ce n’est pas une réponse fantaisiste, mais j’espère que cela aidera!

9
Saber Nomen

J'ai le même problème et aucune des réponses ne fonctionne pour moi. J'ai résolu par les étapes suivantes:

1. Trouvez quel commit contient le gros fichier

git log --all -- 'large_file`

Le commit du bas est le le plus ancien dans la liste des résultats.

2. Trouvez celui qui se trouve juste avant le plus vieux.

git log

Supposons que vous ayez:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git rebase

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

Conseils:

  1. Élément de liste
  2. Je choisis juste drop car les commits contiennent le fichier volumineux.
  3. Vous pouvez rencontrer des conflits lors de la résolution de rebase et utiliser git rebase --continue pour continuer jusqu'à la fin.
  4. En cas de problème lors de la création d’une base, utilisez git rebase --abort pour l’annuler.
3
William Hu